Data Holder

A DataHolder is an object that has little or no behaviour, but lots of data. Generally characterized by many set and get methods.

This is a contentious area of design - the behaviour camp tends to disagree with simple data objects preferring to make objects smarter.

I use get/set DataHolder type objects when they are appropriate. The only argument I've ever heard against them is that they are "not OO enough" or "you are focusing on data and algorithms, not roles and responsibilities". Neither argument gives any concrete reason, just ideologies...

I'd be interested in hearing other peoples opinions and arguments on DataHolder objects (in particular, simple data JavaBeans with get/set methods). -- StephenPetschulat

Sometimes an object really is just a data container, like a ParameterObject, or a memento. I think people who spend a lot of time hand waving over whether a solution fits in line with a given ideology or not aren't solving problems but creating them. Moreover, the SimulaSixtySeven? folks believed that all objects should treated equally, with control smeared throughout them all. The wisdom of time has showed this is very bad. Instead, control should be delegated, controlled, abstracted, layered, etc. just like in real life. So, ideologies, just like methodologies, are crap. And that's my ideology. -- SunirShah

LOL... agreed. I was reading an interesting design case study on the WirfsBrock? site http://www.wirfs-brock.com/pages/resources/html/how_designs_differ.html. It contrasts responsibility vs data/algorithm centered design approaches for a fictitious case study. Her conclusion is that the data driven OO approach is more complex, however, when I read the paper, I can immediately understand the design of the data driven OO approach while the design using the responsibility driven OO approach is not immediately clear (and I've done primarily OO programming & design my whole career). If I am maintaining an application I shouldn't have to get into the "zen" of the designers mindset in order to understand their clever abstractions. The design should make things obvious and simple, not clever, complex, and convoluted. I know RebeccaWirfsBrock has posted here before... I'd be interested in her comments... BTW, in general great set of resources and articles on her site.

-- StephenPetschulat

Personally, I have found that a lot of the code using DataHolder objects seem to be duplicated throughout a program. Moving the logic close to the data (aka ExpertPattern?) reduces this duplication. I don't claim to have enough experience to say that all DataHolder objects are a bad thing, but all the cases I can recall, duplication went down and clarity went up with a more ObjectOriented design. I thus view even accessors as a possible CodeSmell, and evaluate different designs when it pops up.

In the end, it is just a matter of coupling. DataHolder objects are usually extremely strongly coupled with their clients. IMHO, many ideological arguments seem much more sensible when viewed in the light of coupling and cohesion. As always, YMMV.

-- JohannesBrodwall

Interestingly, I find myself frequently using DataHolder objects to reduce code duplication in data ingest systems. ProcessingStage? objects (basically StrategyPattern implementations) in a ProcessingPipeline? know how to filter or update any given JavaBean that is passed to them. Rearranging the stages in an ingest system then becomes a simple matter of configuration, since no ProcessingStage? is coupled to any particular DataHolder class.

-- KrisNuttycombe