The Old Joel on Software Forum: Part 3 (of 5) - Scrabble and Dummy Data Objects

Scrabble and Dummy Data Objects

The title refers to an post on Christian Bepulveda's blog: http://christiansepulveda.com/blog/archives/000038.html (it refers to a recent Martin Fowler essay)

To quote concisely:

"Lately, I've been trying to explain the reasons why dummy-data classes are a smell in software. Dummy Data classes are classes that do not have behavior, only data.
...
Consider Scrabble. When someone presents a word that is challenged, one of the first comments made is "Use 'fazooloo' in a sentence."
...
A dummy data class is like a term that can only be used as an object in a sentence. If no sentence exists in which the dummy data class performs the action, it has no purpose but to be manipulated by others. This has various implications, such as encapsulation violations, but I think the sentence analogy simplifies the reaons to avoid dummy data classes. "

In a nutshell, my problem is this: yeah, OK, that's a smell. But what good is a smell without a refactoring solution?

In case you're wondering, on my current project, we have a "Stuff" object per-implementation that is the rough equivalent of a conf. file. It's not intended to have any behavior. And some of its attributes aren't easily transfered to objects in the domain model.

So my questions to the JoS forum are thus:

* Is it a legitimate concern, or just taking OOP design purity too far? Perhaps it's something you can use infrequently, and not always a bad idea?
* More importantly, what pattern(s) address this issue? What can I do instead of using dummy data objects?

Joe
http://www.joegrossberg.com

P.S. In case you're wondering, I asked on his site and haven't gotten a response yet.

Joe Grossberg
Thursday, December 4, 2003

Some things are just meant to be used by other
things. Not everything has interesting behaviours,
especially at the lower layers where we are making
tactical plumbing decisions a lot of the time.

Is a link in a link list class anything more than
just data?

If data object to interface with a database
any more than just data?

Is a message anything more than just a pile of attributes?

Is your address anything more than just data?

Is a tile in scrabble anything more than just data to
be used by a higher intelligence in playing the game?

It has become fashionable lately, especially in XP,
to remove the role of judgment for simple rules
that are absolutes.

son of parnas
Thursday, December 4, 2003

Some objects are masters, others are... uh....

Oh, never mind.

Emily Litella
Thursday, December 4, 2003

Some objects are inanimate.

I think methods-but-no-data is often worse than data-but-no-methods. An object that's all methods can sometimes be refactored by moving the methods into the classes from which they're getting their data (or the classes they're using to output the results of whatever they're doing). This is most effective if a method is getting all or most of its data from a single class.

Beth
Thursday, December 4, 2003

I think Christian is missing the point of the Martin Fowler essay to which he links.

A dummy data object is not necessarily bad. The bad smell is when your entire (or almost entire) domain model consists of these dummy data objects. This indicates that you have misplaced the domain logic somewhere else (such as service objects).

--
It has become fashionable lately, especially in XP,
to remove the role of judgment for simple rules
that are absolutes.
--

It is more fashionable to read a few blurbs on XP and then make wildly inaccurate assumptions to prove that XP is bad. This has also been the fashion regarding most other methodologies too.

NathanJ
Thursday, December 4, 2003

How does the config data get loaded? Would that logic would be some natural behavior for it???

Scot Doyle
Thursday, December 4, 2003

"How does the config data get loaded? Would that logic would be some natural behavior for it???"

Without getting too technical, our framework sometimes asks the (singleton) Stuff object questions like:

Does this client prefer their dates formatted like "Dec. 4, 2003" or "12-04-2003"?

and then plugs that into a set of templates and code reused/shared by all our customers.

I don't think getting and setting data are what's meant by "behavior".

Joe
http://www.joegrossberg.com

Joe Grossberg
Thursday, December 4, 2003

>It is more fashionable to read a few blurbs on XP and
>then make wildly inaccurate assumptions to prove that
>XP is bad.

Even more fashionable is to dismiss anyone
with a contrary opinion as not educated, because
of course is they were they would agree with me.

son of parnas
Thursday, December 4, 2003

Joe, I wouldn't worry about this too much. This is one of those memes that seems to circulate every so often. Sometimes you end up with data only objects who only know how to load themselves and only know about their own data and ignore the rest of your objects and only interact through getters. It happens.

Lou
Thursday, December 4, 2003

Understood about the getters. I'm wondering about how the data is initially loaded into the object. Is it only through setters or is there a costructor?

Scot Doyle
Thursday, December 4, 2003

Son of Parnas,

Sorry to imply you disagree with me and are thus uneducated. That is just a simple rule that I follow as an absolute ;)

I'm still unsure that XP has anything to say about dummy-data objects though.

NathanJ
Thursday, December 4, 2003

"Understood about the getters. I'm wondering about how the data is initially loaded into the object. Is it only through setters or is there a costructor?"

The data is hard-coded into a class file. Each implementation has one such file for this purpose.

There's a constructor, I guess. When Apache starts, it initializes the framework. The framework initializes a single instance of the client-specific version of that class. It's like a conf file, really ... except that it's an object.

Joe
http://www.joegrossberg.com

Joe Grossberg
Thursday, December 4, 2003

ok, so do i understand correctly that this object has data that is different for each of your customers? and if so, is that data entered by developers (which is why its in a class file) instead of others (which is why it isn't in a conf file)?

Scot Doyle
Thursday, December 4, 2003

NathanJ, i made a strong statement so expect to
be dinged :-)

UncleBob says debuggers are a waste of time
and we shouldn't think, just code little steps
at a time. An ugly procedural solution is the
best bowling game solution because it is the
"simplest." That requirements can be implemented
in any order. All our bugs can be kept on index
cards. Blah blah. And if you have a different
opinion you are just wrong.

son of parnas
Thursday, December 4, 2003

--
UncleBob says debuggers are a waste of time
and we shouldn't think, just code little steps
at a time.
--

I assume you are talking about Rob Martin?
http://www.artima.com/weblogs/viewpost.jsp?thread=23476

Although he does say debuggers are a waste of time he also adds this:

"Programmers can get into the horrible habbit of depending on the debugger instead of on their brain. IMHO a debugger is a tool of last resort. "

I think you have distorted what people are saying and are now arguing with them about things they did not say.

This is similar to the misunderstandings in Christian's dummy-data article. I don't think good developers would say NEVER use a dummy-data object. Instead they see an over-reliance on DDOs as indicating a possible design flaw.

NathanJ
Thursday, December 4, 2003

Well I think the world "smell" covers it here. Dummy Data Objects are a smell -- meaning they aren't ALWAYS bad, and can be used judiciously, but it's something to make you stop and think.

I don't think you can argue that it is often the case that people who aren't used to OOP use dummy data objects a lot, and this can wreak havoc in an object oriented codebase, and with programmers used to programming in an OOP style. That is what is meant by "smell", it's not a hard and fast rule.

Roose
Friday, December 5, 2003

"and if so, is that data entered by developers (which is why its in a class file) instead of others (which is why it isn't in a conf file)?"

Scot, yes. We host the applications on our server for multiple clients.

If they want something changed, on that sort of level, we do it for them.

It's a matter of convenience (simply edit a file, instead of building an interface) and security (these getter methods are often more than just "return 1"; they can have some logic and we don't want them being able to enter arbitrary code, as opposed to just data).

Joe
http://www.joegrossberg.com

Joe Grossberg
Friday, December 5, 2003

Joe, if there is any logic in there, then it seems like it really isn't a simple value object. Given all of this, the only possible refactoring I can see would be to define an interface that exposes any methods common to all of the conf objects (they sound more like customer objects?) and then have the conf objects implement the interface. It is certainly an interesting question.

Scot Doyle
Friday, December 5, 2003

"they sound more like customer objects?"

Yes, in hindsight, CustomerPreferences is a better name than Stuff! ;)

What I meant by logic is that you can, for example call:

prettyDate = Stuff.formatDate(aDate)

where you'd have to pass in a parameter, in addition to simple stuff like:

loginURL = Stuff.getBaseURL() + '/login/'

Joe
http://www.joegrossberg.com

Joe Grossberg
Friday, December 5, 2003

Ok, well I use these Dummy Data Objects on occasion for configuration information read from a config file, and so do a lot of other people who do so and find it beneficial.

That said, we got ourselves a real live Design Pattern here folks. So let's just name it the "Settings" pattern, and call it an well-regarded staple of Orthodox Object Oriented Design and pooh-pooh those who have not been enlightened as to the advantages of the Settings Pattern.

Dennis Atkins
Saturday, December 6, 2003

Dennis, I don't know how sarcastic or serious your second paragraph was, but I hope to bring this up with people who are more purist about their Design Patterns than the practical JoS crowd.

I'll see what they think of the "Settings" pattern and if they have any other approaches. I've started reading Fowler's "Patterns of Enterprise Application Architecture" on Safari (O'Reilly) and maybe this ground has already been covered.

In any case, you can check the progress here: http://www.joegrossberg.com/archives/001064.html

Joe
http://www.joegrossberg.com

Joe Grossberg
Monday, December 8, 2003