File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Objects without behavior, what's the alternative?

 
Garrett Rowe
Ranch Hand
Posts: 1296
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic