Re: delegation vs. inheritance

Hi Ed,

Thanks for your interesting remarks. Re-reading my own
messages it seems a lot of them are stated way to absolute. Thanks for
your response in that respect. Ofcourse you are very right to say:

"There's no Absolute Software Law out there that says
it's better to put method X in Class A rather than Class B"

Then again for me and for the people whom I teach and mentor there are
quit a few quidelines or heuristics that seem to work in making those
decisions. Most of them are non-technical in nature, and in my
experience that constitutes a big part of the problem for mostly
technical oriented people.

When you say:

"For me, OO is flexibility through
variance encapsulation: so if you're not sure in which class to put a
method, consider how the classes will develop over time"

It might be an ideal case where domain specialists and object
designers also make a prognosis about the state of the domain in say 5
years. Lots of times I dont see that effort made. Then with the
"variance encapsulation" argument we might create a "purely
technical" discussion about object design. From that we might have
objects less recognizable by domain experts just for "the sake of
technical arguments". I see that kind of "technical design" happen
and see it beat up every domain modelling effort very fast. Mostly
with it you get comments about the "idealistic or unrealistic"
analysis model. Its not my way.

Flexibility alone is not a good argument for a design imho. That might
drive us into abstractions for the sake of being abstract. I consider
that another way of the technicians taking over design. Seen that too.
What we might need more is goal oriented abstraction for which domain
concepts provide good objects. And it should too. To me its the
responsibility of the domain/business to give enough of a
differentiated view of itself so that it can modelled in software and
in business.

Then about design patterns you comment
"
I'd be hesitant to make so broad a statement as, "Objects should have
bevahiours and state." It could be argued that the GOF state pattern,
for example, decomposes behaviour into a central object that's aware of
the state (the context) and all the individual state objects that,
"

Yes ofcourse lots of design patterns ( how about strategy for
instance) show tendencies towards either managerial omnipotence or
property bag impotence. The whole distinction between behavioral and
structural patterns in the GOF book points to this. The interesting
aspect being for me that although they all show tendencies towards
either site nowwhere but in the state/strategy patterns it seems
totally out of balance.

The primary heuristic you cited above for me is of a different level.
If designers are competent to work with the primary, the patterns of
collaboration between objects and classes will arise more naturally.

Therefore in my experience it might even be ill-advised to work
directly with design patterns catalogs. It has the risk of
overemphasizing collaborations between objects where object identitiy,
recognizability and independency might be offered.

Thats probably the reason I throw some very absolute statements too.
Its not so easy to really work with the primary and to keep working
with its effects and we get easily distracted into "sound technical
discussions" or pretty sounding technical discussions about object
design.


Regards,
Rick



Op 7 Aug 2006 15:53:49 -0700 schreef "Ed" <iamfractal@xxxxxxxxxxx>:


Rick Elbers skrev:



The anti pattern has to do with systems. The objects in a system are
balancing each other to provide the needed equilibrium in the whole
system. You might look up work of of for instance Bateson to learn
more about systems theory. In this example it means that if you are
starting to have objects which mainly encapsulate behavior and no
state somewhere else you will have objects which display the opposite:
state but no behavior( I call that property bags). In my experience
good ooa/d has to do with finding true OBJECTS that is things that do
AND know( ergo has state AND behavior).


Hi, folks,

An interesting discussion you're having, though I must admit, I'm not
entirely sure I've understood the direction it's taking, so I apologise
in advance for any misunderstandings.

Firstly (I'll reference all from this post rather than isolated
replies), Thomas you mentioned in your first post that, "My idea was to
simplify huge classes by dividing them ..." and Rick replied, "If you
have huge classes probably your problem
domain is insufficiently analysed;" with which I agree.

Then Thomas you wrote that, "Basicly I want to use it to provide a way
to safe memory ressources in
case application that base on a similar datastructure are merged to one
application," which I hope you'll forgive me by rephrasing (if I
understand correctly) as, "Basicly I want to use it to provide a way to
save memory ressources in
case this application and an application that's based on a similar
datastructures are merged to one application." So you're working on one
application, and think it might be merged with another existing
application out there at some time in the future. I'm not entirely
convinced that two applications can be cost-effectively merged just
because they share the same data-structures; most banking applications
would share the same data-structures, I imagine, but merging VISA's
banking system with the system used by Citibank sounds like a nightmare
to me. The important thing here, however, is that you're looking to,
"Save memory resources," and that's not a primary goal of OO.

(A very minor point - and here perhaps I'm misunderstanding just for
the sake of it - but Rick then gave the advice, "Define as many strong
independent objects as you can ...;" I've never seen an independent
object myself :)) (There's no good way to end a bracketted aside that
ends with a smiley, is there?)

Then we come to what may be the central problem here when Thomas says,
"Somehow I am not really comfortable doing so. I am still searching for
some justification to put some responsibilities / behaviour in a
certain class. Because I can't see whether to put the "divide" methode
in the graph or the contour, I would thing that it might be good to add
a class that makes it purpose clear."

Thomas: it's ok. There's no Absolute Software Law out there that says
it's better to put method X in Class A rather than Class B in the
border cases that you're talking about; no policia will tear you from
your bed one stormy Tuesday night. For me, OO is flexibility through
variance encapsulation: so if you're not sure in which class to put a
method, consider how the classes will develop over time; if your
abstractions are sound, and one abstraction will clearly offer more
implementations in future than the other, then it should own the
method. I know that, "If your abstractions are sound," clause is
exactly the question you're asking, but thinking about flexibility (not
memory-resource savings or, as you mentioned somewhere else,
understandability) will generally see you on the right path.

Another important question to come out of all this is: what is the
granularity of your encapsulation? In other words: are you using C++
namespaces? I presume you're not, as you are asking very class-grained
encapsulation questions. Some of your problems are solved by
namespaces, as you then have a much larger grain of encapsulation, and
so you're free to hand over much, "Bigger," problems to other parts of
your code. This is not a small point. With namespaces you can have most
of your code say, "Well, I don't care whether a Contour or a Polygon or
ContourSplitter does what I want, I'll just hand this over to
GraphFacade, and let it worry about whether it wants to delegate or
pass to a subclass." This encapsulates one part of your code from
another, thereby making it more flexible, and that's the bottom-line
(particularly if you're employing a hierarchical namespace, see:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs70.html).

Finally, we come to Rick's, "In my experience
good ooa/d has to do with finding true OBJECTS that is things that do
AND know( ergo has state AND behavior)."

I'd be hesitant to make so broad a statement as, "Objects should have
bevahiours and state." It could be argued that the GOF state pattern,
for example, decomposes behaviour into a central object that's aware of
the state (the context) and all the individual state objects that,
themselves, just contain behaviour (for their unique states) (see my
own small offerings, in which a series of states have no state
information themselves [apart from knowing which state comes next] and
just own behaviour at:)
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs60.html

.ed

.

Relevant Pages

  • Re: For Sean Pitman: Review of "Meaningful Information"
    ... They are just looking for something that humans have an higher ... human-like design is not easily detectable. ... that all simple patterns are the result of intelligent design. ... What is 'informational complexity'? ...
    (talk.origins)
  • Re: (OT) Giving up on science [Was: Giving Up on Leopard]
    ... As you may know, both the Hebrew and ... of design that cannot be accidental or just coincidence. ... mathematical patterns run through the entire Bible, ... When you subtract a multiple of 7 from a multiple of 7 ...
    (comp.sys.mac.system)
  • Re: John Conways game of Life and order from chaos
    ... mathematically proven to be gardens of eden. ... designed patterns), but if I recall you don't really have any IDers ... instructive to calculate the CSI of a Garden of Eden pattern or two and ... functional information is not the hallmark of design as ...
    (talk.origins)
  • Re: Ever heard of Potato Semiconductor?
    ... product more reliable over time than they were when the engineers first let ... design engineer... ... When I was installing our first voltage contrast electron ... I've worked with technicians who thought that they were ...
    (sci.electronics.design)
  • Re: How inaccurate is a 555 or 7555 REALLY?
    ... John Fields wrote: ... you design to keep from confusing folks? ... service engineers who are prepared to ... If the design wasn't transparent to the final test technicians, ...
    (sci.electronics.design)