An object which merely contains some data and provides either public access to the data or get/set methods for the data, without any augmentation of behaviour. In this programmer's opinion, violates the very concept of ObjectOrientedProgramming, which is primarily that behaviour and data should be gathered *together* into a class. Use of the pattern/antipattern definitely violates encapsulation.

Also known in some circles as Slutty objects.

See BeansConsideredHarmful.
-- JeffBay

An OO purist to the bone :) has thus spoken. Pragmatism however says otherwise in quite a number of situations. For example you need to transport some data back and forth between GUI objects and business logic (with a controller as in MVC, or using other settings for non OO purists). Some OO purists may say that you don't need to do that, you'd rather have something like:
  userProfile.displayOn(editUserProfileDialog);
I don't know, about that. Non OO purists like me, might prefer:
  editUserProfileDialog.setData(userProfileData);
Where userProfileData is a struct. And the reason for this being that this way I have less coupling between modules, better testability, etc. Otherwise the same data object can have various views. It's best the responsibility of the view to know what data is relevant and how particularly should be laid out in a particular context. Also a view in general, should be dependent only on the data structure it represents in its fields and not on a particular class in the object model. Yes, we can create adapters, etc, between the model and the view to get rid of some of the drawbacks exposed and decouple things while avoiding dummy structs, but hey, those are just extra stuff that add a bit to the complexity of the project, while structs are just structs. If we have any doubt that java does not provide structs for a good reason, we can only see other smart languages like ML, Haskell, Ocaml, Scheme, Lisp ,etc. They all support structs (and many other cool things), so they cannot be '''that bad''' after all. --CostinCozianu

Amen.  Structures (as we called dumb data objects before TheChurchOfOoBigots ruled they were a sign of apostasy) have their uses.  The most common I run into is when a method needs to return 2 facts that haven't been previously related.  At some point in the future it might make sense to refactor some behavior to the structure, but there's no reason to invent some now just to uphold the very concept of object oriented programming. -- EricHodges


It should be noted as well; that for many datatypes the DumbDataObject is appropriate.  For most business objects it isn't, but for lowlevel things like pair<T> (in C++), the most appopriate interface is just to get and set the two elements.  Not much is gained by making the user go through getters and setters--and frequently much is lost.  Unless the language can handle lvalue return-types--C++ and CommonLisp can, many other languages cannot--you may use the ability to use the object's field(s) in the left-hand side of an assignment statement.  (This might well be a religious issue; some may argue that x.set_foo(y) is always preferable to x.foo = y...)--ScottJohnson

----
A useful rule: any object that will be serialized and sent over the network must be a dumb data object. Of course you don't actually want to pass dumb data objects around locally, so wrap it immediately after you deserealize it.

----

See also PlainOldData, PerniciousIngrownSql