I have read around in a number of places that objects without behavior are not really good objects at all. I know they're pretty boring, but are they evil? Consider an application that reads *records* from some census data, and then gives some information in response to a user query.
[story] User: request information on the name Garrett Rowe
Computer: Garrett is the 157th most common name in the U.S. for males, 0.0126% of the U.S. male population is named Garrett. Rowe is the 361st most common surname in the U.S., 0.0035% of the U.S. population has the surname Rowe. Based on a population of 200,000,000 U.S. citizens, it is likely that 22 people are named Garrett Rowe. [/story]
(Note: all data and calulations are made up off the top of my head, take nothing as fact)
My first instinct would be to code a method which parses some String of text into a CensusRecord and stores it.
However I can't conceive of any behavior a CensusRecord would have. I envision it as a pure record, which give access to its data fields (name, relativeNameFrequency, etc.) but the actual heavy lifting would be delegated to one or two *smarter* classes which could receive a CensusRecord, or a collection of CensusRecords and a query String, and craft a response. Put another way, a CensusRecord shouldn't know or care or forsee how it can be used, but solely make available its data. Its a pretty dull object, but the data it encapsulates is essential to the final output of the program. Should it even be called an object at all? Why even bother hiding its data?
[ December 28, 2006: Message edited by: Garrett Rowe ]
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Yes, sometimes such "objects" aren't the worst thing to have. As long as you are aware of the fact that they are very *weak* objects, and keep an eye open for giving them more responsibility, I wouldn't worry *too* much about it.
And I agree, hiding the data in that case doesn't have much benefit.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Such "struct" objects often appear in data transfer situations where you just need to send data from one component to another. I've also made them to simplify constructors - one arg instead of ten. I always look twice at them to see if some richer object model might help, but sometimes there's no need to do more.
One guideline is that if you ask an object for a couple fields and do some logic with them, and even worse put the results back into the object, that code might belong in the object, too. I don't think formatting your message about census data counts as logic that would be better in the object, so it's ok as a struct. For now.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jul 11, 2001
Originally posted by Stan James: Such "struct" objects often appear in data transfer situations where you just need to send data from one component to another.
DTOs. In distributed systems, you don't even *want* them to have logic.
I've also made them to simplify constructors - one arg instead of ten. I always look twice at them to see if some richer object model might help, but sometimes there's no need to do more.
A Parameter Object. For those I find that they often "attract" behaviour over time.