Re: How should a container class "know" its contained objects?
- From: "Daniel T." <daniel_t@xxxxxxxxxxxxx>
- Date: Thu, 17 Jan 2008 07:44:56 -0500
Veloz <michaelveloz@xxxxxxxxx> wrote:
"Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
Veloz <michaelve...@xxxxxxxxx> wrote:
I've done some more digging and found a couple other nuggets
out there, mostly from Martin.
Here's one:
"We [should] create objects of the things that have behavior,
not the things that carry data.."
This makes sense to me on a bunch of different angles.
But, then, where does that leave the modeling of the data?
Does the data not deserve some representation in our
application?
The obvious answer is "yes", that data needs to be modeled in
some way.
Joe has a robot with type A arms, a robot with type B arms, and a
robot with type C arms.
Mary has a robot that can do job X, a robot that can do job Y,
and a robot that can do job Z.
Now, if Joe wants to sell you a robot, you have to ask him, "but
what jobs are these robots good for?" Whereas if Mary tries to
sell you a robot, you don't really worry about what kind of arms
they have...
The data is less important than what job the class does.
Agreed overall.
Let's say one of the functions Mary's robots know how to do is to
perform some custom analysis on something known as a ZippyBook.
The ZippyBook is a domain concept that somewhat mimics a real book.
It can contain chapters, an index and so on. Now, it's pretty easy
to conclude from past conversations that the most
interesting/useful modeling will revolve around the custom
analysis, because that's where the most interesting/important
behaviors are.
[Structural analysis snipped]
You have animated the robot, but not the zippy book. What does the
ZippyBook do? You have expressed the entire problem as what the robot
(and UI) does to/with ZippyBooks but left ZippyBooks completely
inanimate.
As I said before, if all you are doing is taking data, transforming it,
then presenting it, then you will come up with a representational model,
not an OO one. Importantly, as part of such a process you will end up
with a monolithic "You" in the program. The thing that does all the data
manipulation. In this case, you call it the "robot", before you called
it the "application". You haven't yet undergone the paradigm shift, you
haven't decentralized your thinking...
The newcomer to object technology will face suggestions such as
"Before you can truly be an object-oriented developer, you will have
to undergo a paradigm shift." While this sounds a bit dramatic, there
is a kernel of truth to the notion of a paradigm shift. The software
developer needs to think in a decentralized fashion, rather than
follow the typical centralized control of the structural approach.
(Riel, "Object-Oriented Design Heuristics")
I must say it is easier for me, I write video games for a living, lots
of animated things interacting...
.
- References:
- How should a container class "know" its contained objects?
- From: Veloz
- Re: How should a container class "know" its contained objects?
- From: Veloz
- Re: How should a container class "know" its contained objects?
- From: Daniel T.
- Re: How should a container class "know" its contained objects?
- From: Veloz
- Re: How should a container class "know" its contained objects?
- From: Daniel T.
- Re: How should a container class "know" its contained objects?
- From: Veloz
- Re: How should a container class "know" its contained objects?
- From: Daniel T.
- Re: How should a container class "know" its contained objects?
- From: Veloz
- Re: How should a container class "know" its contained objects?
- From: Daniel T.
- Re: How should a container class "know" its contained objects?
- From: Veloz
- How should a container class "know" its contained objects?
- Prev by Date: Re: Business objects, subset of collection
- Next by Date: Re: question about component integration or assembly
- Previous by thread: Re: How should a container class "know" its contained objects?
- Next by thread: Refactoring into ravioli code
- Index(es):
Relevant Pages
|
Loading