David Avendasora wrote:
Arturo,
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.
Ah ha! I knew that I was just not quite looking at it from the right
direction! This is so much better than how I'm doing it. Correct me if
I'm wrong: the Label class will have a method that simply calls
part.copyToLabel(this), then the part's copyToLabel(Label) method will
write back to the given Label all the various values that it knows
about, instead of the label needing to know what to do for each type
of part.
You need to look at it from the model-view-controller POV. The model is
Part. The view is Label (or HumanReadable as views may be for other
subsystems). The controller is either WO or a custom subcontroller for
your application. The controller is the thing that does
fetch Part from DB.
create Label
part.copyToLabel(label).
display.
The controller's job is to coordinate the activities amongst the models
and views. Usually WO takes this role. From a certain POV the Label
shouldn't know that it is displaying Parts so it should not be calling
part.copyToLabel() itself. The Part needs to provide information to
Label so off the cuff I don't see how to avoid that coupling. Something
along those lines, anyway :-)
-arturo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
