• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Newbie Key Value-coding and Subclasses Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Newbie Key Value-coding and Subclasses Question
      • From: David Avendasora <email@hidden>
References: 
 >Newbie Key Value-coding and Subclasses Question (From: David Avendasora <email@hidden>)
 >Re: Newbie Key Value-coding and Subclasses Question (From: Arturo Perez <email@hidden>)
 >Re: Newbie Key Value-coding and Subclasses Question (From: David Avendasora <email@hidden>)
 >Re: Newbie Key Value-coding and Subclasses Question (From: Arturo Perez <email@hidden>)
 >Re: Newbie Key Value-coding and Subclasses Question (From: David Avendasora <email@hidden>)

  • Prev by Date: Re: Some help with Optimization
  • Next by Date: Re: AJAX - Validation and obtaining component's generated HTML
  • Previous by thread: Re: Newbie Key Value-coding and Subclasses Question
  • Next by thread: Re: Newbie Key Value-coding and Subclasses Question
  • Index(es):
    • Date
    • Thread