Data vs. Behavior Objects?
Tim Visher
At my most recent Philly JUG meeting the presenter said something that
was very interesting to me. I may not have gotten it 100% right but I
talked with a few people afterwards and it was enough to trouble me.
Essentially, the presenter said that he believes that there are two
kinds of objects, Data objects and Behavior objects. Behavior objects
hide their data and expose their behavior. Data objects expose their
data and have no behavior. And the real kicker is that really the two
should never intersect.
The upshot of this was essentially that class with behavioral
information (methods) should not have getters and setters because
there should never be a need to see its data. Any class with a getter
and a setter shouldn't have any behavioral methods.
For full disclosure, I'm basically just out of college with very
little real world systems experience.
What confuses me so much about this is that in almost everything I've
read, the big(gest?) win of object orientation is that you get to
group your data w/ the stuff that works on that data. So, in other
words, you should _always_ have your data and behavior together in a
single class.
One of the examples brought up was validation. This was interesting
to me because I just had a long debate internal to my company over
whether or not we should have a separate Validator class which knew
how to validate a certain essentially data class, or whether we should
package the knowledge about how to validate the business object within
the class itself, thereby packaging the data with any and all methods
that need to work on that data. Essentially, what I heard at the
meeting was that my position (packaging validation w/ data) was
stupid. I didn't really get to hear why.
Needless to say I'm very intrigued because this would be kind of a
fundamental shift in how I think about Object Orientation. A few
people in the discussion said that Uncle Bob had written about this
concept but 30 minutes or so of Googling didn't lead me there
(although my Google-fu is weak). Any reading on the subject or just
your own thoughts would be helpful.
Thanks so much!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
Mark Nijhof
Mark Nijhof
asked in the DDD list all, I would recommend reading up on DDD all
together.
-Mark
Curtis Cooley
idioms, ideas, practices etc... but when I hear someone say never or
always, I get nervous.
Second, check out
http://blog.objectmentor.com/articles/2007/11/02/active-record-vs-objects
which essentially says the same thing but only with relation to ORM
tools.
I've heard this 'technique' before, and I'm not buying. You're better
off looking into things like constructor injection which endorse
creating objects in the wanted state then not changing them. See "good
citizen" at http://www.picocontainer.org/patterns.html
There are also those who advocate immutability so objects shouldn't
even have setters.
Bottom line, shoot for objects with loose coupling and high cohesion
and go from there. It's really really hard to build a system with
loosely coupled and highly cohesive objects that is hard to maintain.
And building maintainable systems is why we bother about all this
stuff in the first place.
Curtis Cooley
curtis...@gmail.com
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
Zach Shaw
If you're looking for more information on the topic I'd suggest looking at Martin Fowler's article on Inversion of Control http://martinfowler.com/bliki/InversionOfControl.html - It's also commonly called the hollywood principle. This technique allows you to have objects with much more behavior - and expose less data. There's a ton of information out there on the topic. I'd also suggest checking out the mock object guys - http://www.mockobjects.com/ . And I'm guessing the Uncle Bob article is his dependancy inversion one http://www.objectmentor.com/resources/articles/dip.pdf .
Part of the idea is about data encapsulation - you can't ask me for data - but maybe I'll give you some, but it's my choice, only if I like you. The more getters you have the less encapsulation you have.
> What confuses me so much about this is that in almost everything I've
> read, the big(gest?) win of object orientation is that you get to
> group your data w/ the stuff that works on that data. So, in other
> words, you should _always_ have your data and behavior together in a
> single class.
My interpretation of the behavior world is that it's okay to have a behavior object that has a data object, but the behavior object just shouldn't expose that data object.
It's a different way of coding - and maybe not the "best" way at all, in fact at sdtconf a few weeks ago I got in a big debate about around this topic - Here are the related blog posts:
http://www.agiledeveloper.com/blog/CommentView.aspx?guid=8b6d0c24-1b69-4df2-9ddd-de86c3556688
http://zdsbs.blogspot.com/2009/10/hollywood-dilemma.html
I hope that helps.
-Zach
Raoul Duke
As others have said, there is a lot of "it depends" in good software
engineering. At a very high level, the super zen gestalt super power
is to not think ahead of time about rules and patterns but to ingest
the needs of the system and evolve whatever is appropriate for that
particular situation. Hard to do. I cannot say I am super good at it.
cf.
http://gojko.net/2009/02/27/thought-provoking-tdd-exercise-at-the-software-craftsmanship-conference/
> One of the examples brought up was validation. This was interesting
> to me because I just had a long debate internal to my company over
> whether or not we should have a separate Validator class which knew
> how to validate a certain essentially data class, or whether we should
> package the knowledge about how to validate the business object within
> the class itself, thereby packaging the data with any and all methods
> that need to work on that data. Essentially, what I heard at the
> meeting was that my position (packaging validation w/ data) was
> stupid. I didn't really get to hear why.
There have been some fun rants cf.
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html which
are perhaps along those lines.
In the end, they might be goals to keep in mind if there are no other
influences telling you not to go that route. But as soon as you know
of a reason to back off from that extreme, you should. For example:
what if the same data has N different possible reasonable
business-based Validations that can be run on it. Would you really
package them all up in the same ascii source file?
sincerely.
Kevlin Henney
>
> Essentially, the presenter said that he believes that there are two
> kinds of objects, Data objects and Behavior objects. Behavior objects
> hide their data and expose their behavior. Data objects expose their
> data and have no behavior. And the real kicker is that really the two
> should never intersect.
I think that is fair to say that there is a spectrum, with
behaviour-centric objects at one end and data-strong objects at the
other (actually, it's more complex than that... but that's another
posting). By stating that it's spectral rather than polar, I'm
basically disagreeing that the distinction is absolute rather than a
characterisation of degree and these two kinds of object should never
intersect.
Sure, there are cases where adopting such an approach will be an
appropriate style, but that should be considered a context-specific
judgement rather than an absolute mandate.
We can find good examples of objects at each end of the spectrum, such
as command and strategy/policy objects being behaviour-centric and
value objects and data-transfer objects being data-strong, but we can
also find other decent examples that lie along this range, such as
aggregate objects that combine both data presence with behavioural
integrity.
> The upshot of this was essentially that class with behavioral
> information (methods) should not have getters and setters because
> there should never be a need to see its data. Any class with a getter
> and a setter shouldn't have any behavioral methods.
The getter/setter issue is almost orthogonal to the
behaviour-versus-data distinction, so it's probably worth keeping
these separate. A DTO may have getters, but it need not necessarily
have setters. A VO may be more focused on simple behaviours than it is
on getting anything -- let alone setting (again, more to this topic
than is probably relevant here).
> What confuses me so much about this is that in almost everything I've
> read, the big(gest?) win of object orientation is that you get to
> group your data w/ the stuff that works on that data. So, in other
> words, you should _always_ have your data and behavior together in a
> single class.
The big win is that you can. It doesn't mean you always should do so
or do so in equal quantities. For example, strategy objects are often
dataless but strong on behaviour. So, moving away from the polar view,
it is a matter of degree. It makes more sense to focus on object
responsibility to reveal the nature/flavour/emphasis of an object, and
organise the data and behaviour accordingly, rather than leading with
a data-versus-behaviour or data-and-behaviour view -- that puts
solution assumption ahead of problem consideration.
> One of the examples brought up was validation. This was interesting
> to me because I just had a long debate internal to my company over
> whether or not we should have a separate Validator class which knew
> how to validate a certain essentially data class, or whether we should
> package the knowledge about how to validate the business object within
> the class itself, thereby packaging the data with any and all methods
> that need to work on that data. Essentially, what I heard at the
> meeting was that my position (packaging validation w/ data) was
> stupid. I didn't really get to hear why.
Depends what it is. I use an ISBN example in a couple of my courses.
Putting ISBN validation anywhere other than the constructor of an ISBN
class's constructor is an awkward (but popular) allocation of
responsibility. On the other hand, I wouldn't want to see objects
whose validity was dependent on a broader and more complex set of
relationships suddenly weighed down with a bucket of dependencies and
bookkeeping just so that validation could be collocated.
Kevlin
--
________________________
Kevlin Henney
+44 7801 073 508
http://curbralan.com
http://kevlin.tel
________________________
Jason Catena
> One of the examples brought up was validation. This was interesting
> to me because I just had a long debate internal to my company over
> whether or not we should have a separate Validator class which knew
> how to validate a certain essentially data class, or whether we should
> package the knowledge about how to validate the business object within
> the class itself, thereby packaging the data with any and all methods
> that need to work on that data.
Either of these approaches tangles a crosscutting concern (validation)
with a distinct purpose (the business object).
It's not clear which way to bundle it because independent objects is a
bad abstraction.
A separate Validator class is too far away from the business object
class, it focuses on the validation, and you must make it aware of all
business-object-specific bits anyway for it to do its job.
Validation rules bundled in the business class is too close, because
you don't get to abstract and reuse the common bits, which would make
validation as a concern easier to change.
Aspect-oriented programming
(http://en.wikipedia.org/wiki/Aspect-oriented_programming eg AspectJ)
was invented to deal with this: you reuse your basic business-object
class, separately create validating code (customizing itself if
necessary for the code it's validating, via reflection), and then
describe the points at which the compiler (ie weaver) joins the
validation code into the business object (eg, as a method
enters/exits, to verify pre- or post-conditions).
> http://five.sentenc.es/ - Spend less time on e-mail
Jason Catena
Raoul Duke
> (http://en.wikipedia.org/wiki/Aspect-oriented_programming eg AspectJ)
> was invented to deal with this
i'm sure there are a bunch of different opinions here, but my $0.02 is
to stay away from AOP if only because the debugging/maintenance side
of things get significantly more convoluted.
sincerely.
LudovicoVan
> Sorry wrong list, not here but in the DDD list. But since this was not
> asked in the DDD list all, I would recommend reading up on DDD all
> together.
to a serious engineering book, where such notions as objects and
behavious have a clear a rational meaning. I mean: the good old days
when informatics was an industry, not today's joke and speculation.
-LV
LudovicoVan
> First off, there are no 'rules' in software development. There are
> idioms, ideas, practices etc... but when I hear someone say never or
> always, I get nervous.
are the Principles, there are the Key Factors, and there are the Best
Practices. And so on.
-LV
Raoul Duke
> are the Principles, there are the Key Factors, and there are the Best
> Practices. And so on.
don't forge the Gross Errors And Misconceptions!
LudovicoVan
> > I'd suggest people get a grip on some good old enginnering book: there
> > are the Principles, there are the Key Factors, and there are the Best
> > Practices. And so on.
>
> don't forge the Gross Errors And Misconceptions!
reminder...
-LV
Steve Donie
LudovicoVan
> Just wondering if you can give some examples of "Good Old Engineering"
> books.
Robert Hanson on Apr 29.
http://groups.google.co.uk/group/software_craftsmanship/browse_frm/thread/9373634933dc829d?hl=en#
-LV