Re: Newbie Key Value-coding and Subclasses Question
Re: Newbie Key Value-coding and Subclasses Question
- Subject: Re: Newbie Key Value-coding and Subclasses Question
- From: Arturo Perez <email@hidden>
- Date: Fri, 10 Feb 2006 10:27:47 -0500
David Avendasora wrote:
Hi Arturo,
I have a reputation as being a bit ummm *strict* in my interpretation
of what the proper O-O way is of doing things. It has served me well
with code and less so with ppl :-)
No worries! This is my first OO programming project and being
*somewhat* over the age of 14, I'm having a slow time reconciling it
with my *strict* Relational Database design background. I'm trying to
be OO, but sometimes I wake up in the night screaming "It's not
normalized, it's not normalized!!!" Be strict. It helps me.
Oh goodie! I get so tired of people saying STFU :-)
The problem isn't so much with doing the above or using instanceof.
The problem is that once your code becomes aware of object-types then
you're on a slow sure path to perdition. You might want to take a
look at the book HeadsFirst Design Patterns (the typical GoF
reference is too heavyweight for most developers) for reasons to
avoid instanceof et al.
I have bought it and am currently about a third of the way through. I
understand the write to an interface and not to the implementation
concept, but I am having a hard time understanding exactly how to
apply it in this situation.
The "write to an interface" thing is handy but it assumes that your
object model is reasonably correct. That way you can vary the
implementation without unnecessarily disrupting your application. One
way of thinking about it is to use interfaces only but not classes
between separate logical modules. You can see that just having
interfaces doesn't protect you from misjudged API design.
All I'm doing here is copying some default data from a Part object to
a Label object. Depending upon what type of Part (Raw, Intermediate or
Finished) they have different subsets of information. All three have
some things like partDescription but only a Finished has unitQuantity
so I have to figure out what type of Part it is first to know what
information I can get from this part. I suppose I could create an
interface of "Labelable" and require all Part types to have the fields
I'm pulling so I wouldn't have to worry about what type of Part it is,
but then I'm solidifying some UI convenience as a requirement in the code.
I am not much in favor of either of your suggestions. How about having
an abstract method in your Part superclass called copyToLabel(Label).
Then your subclasses just need to implement that and you no longer need
instanceof or anything similar. This is what is intended by
polymorphism. Your class morphs as necessary into the correct thing
without you needing to code it yourself. Although, from your
description, it might be better to view it as copyToHumanReadable() and
then take it from there.
Another alternative is to for each part type to put descriptive
information into a hashtable. WO can then use WOConditionals to display
the appropriate information based on whether a hashtable key exists.
For example, WO can mostly automatically do something like (if
hashtable.get("unitQuantity") then display hashtable.get("unitQuantity")).
I opine that either of the above will get you the flexibility you need
without casting much, if anything, in code.
In terms of the UI convenience thing, well you do at some point *have*
to support the UI. I imagine you may be able to create a view object
that can deal with all the various part types but there be dragons that
way, too.
At this point I'm sure you are going to as "Why are you copying the
data? Just use the relationship to grab the information from the
associated Part." The problem is that a Label can potentially use
different information, I'm just copying this info across as the
default. The user can change it to something else, although they
usually won't.
IIRC, the proper WO way of doing things is to use single table
inheritance for the above situation. Is that what you're doing?
(sheepishly) No, I'm using Vertical Inheritance, even after reading
all the admonishment against it in the WO documentation. See the bit
about my dreams above.
That's not so bad. But since I thought your table has a column already
called partType I thought horizontal was the way to go.
_______________________________________________
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