Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
- Subject: Re: EOGenerator & Inheritance (on Inheritance vs Status pattern)
- From: Arturo Pérez <email@hidden>
- Date: Tue, 14 Feb 2006 00:03:19 -0500
-arturo
On Feb 13, 2006, at 6:10 PM, Ian Joyner wrote:
On 14/02/2006, at 2:32 AM, Arturo Perez wrote:
Ian Joyner wrote:
On 13/02/2006, at 4:09 PM, David Avendasora wrote:
I and a new OO programmer and I *really* appreciate everyone's
advice on OO design!
In this case, these three part types have some very specific
differences. It is not one part that changes. My application is
being built to manage the manufacturing in a bakery.
- Raw parts are sugar, flour, oil, etc. and are usually procured
from outside vendors.
- Intermediate parts are things like dough, toasted coconut and
such where an intermediate part has a Bill of Materials and
requires work within the manufacturing line to have produced.
- Finished parts things like like cookie, bar, etc. and are parts
made up of any number of Raw and/or Intermediate parts. Since they
are sold to customers they also have to have additional attributes
like UPC code, customer specific attributes.
Does this still sound like something that would work better as an
implementation of the Status Pattern, or should I stick with
Inheritance?
OK, that clarifies it and I think your inheritance design is
probably fine. Do these three kinds of things have features in
common? Data values (either attributes or typed functions) and
procedures (untyped (void) functions). What I do think you'll have
is for the intermediate and final parts, as 'has-a' relationship
'ingredients'. Make sure you don't mix up the is-a (inheritance)
with has-a (component-of) relationships. Otherwise inheritance is
fine.
Ian
Right, and I think, generally speaking and as discussed in Head First
Design Patterns, one should favor composition over inheritance.
Inheritance can lock you into design choices since no common language
allows modification of inheritance hierarchies at runtime.
So, I would design Finished as a container for Ingredients and
Ingredients as containers for RawMaterials. Using Ian's language
Finished has-A Ingredient etc.
Well, I think each has a (sorry for pun) different role. Inheritance
is really about identifying common properties and putting them in one
place – thus about decomposition first, with inheritance being the way
to put it back together. While you can put things back together with
composition, inheritance offers a higher level of abstraction which
replaces lower-level language mechanisms such as #include and import
(although hybrid languages still rely on such code maintenance
facilities).
That may be. I think most ppl use inheritance incorrectly because of
the way that it is taught. Most view it as a form of taxonomy
(Mammals->Ursa->Grizzly or Numbers->Real->Integers) when oftentimes the
abstractions required in our profession are not so neatly categorized.
You are right though that inheritance expresses fixed state vs
changeable state, so that is a consideration in whether to use it or
not and to avoid inappropriate use.
What is "Head First Design Patterns"? Is it a book or paper? Although
I'm a bit dubious about "Patterns" because it was something done for
20-30 years (algorithms and data structures) before someone invented
the term pattern as if it were something new ;-( ;-). Maybe it's
better that the all-to-frequently patternless and unstructured kind of
programming we too often see.
Head First Design Patterns is a book, one of a series by the Head First
ppl. I like it because it has funny cartoons :-). The Gang Of Four
book is too dry, boring and not relevant to most developers.
Personally, I don't like treating patterns as manna from heaven but
they have their uses. My feeling is that most developers use patterns
as a crutches. Now, sometimes one needs crutches but when one spends
all of one's energy limping about then something is wrong.
-arturo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden