Thanks all for your help-
I wasn't clear enough, I agree, and sorry about that, but there was a
hint hidden in my text:
> (I'm going to have categories to handle drawing, material takeoff,
pricing, etc for each door type).
We manufacture entrances (and many doors). The users of this app enter
data from customer orders and my app generates pricing and build
information. The users do need to be able to change the type of door
(because often the customer will change it during the process). It's
extra nice not to lose any data during these changes (although some
properties get reset during a type change).
I think the direction I'm going to go is to put all the properties of
all the door types into the base class, but still have subclasses so
that I can separate out all the various methods and categories that
are going to be specific to each door type.
I'm sorry if this was borderline not cocoa (and more obj-c or data
structure theory or something), but I definitely want to utilize
patterns that are most compatible with Cocoa so I felt it was
reasonable that it be asked here.
Thank you all again, I have read each of your responses 5 times :)
On Nov 4, 2009, at 1:47 PM, Paul Bruneau wrote:
Hi-
I'm in early development of an app (non-core data, NSDocument app)
that will deal with a lot of doors. I have created a door object,
SLDoor, which currently contains all of the properties that might be
used by any of the several types of doors.
There is a doorType property which is what determines which of the
types of doors a particular instance is.
This means that if you choose a door type, many properties that are
only used by any of the other types will go unused. On the other
hand, it's very good for if the user wants to change the door type--
the properties are all there ready and waiting.
But I did have the idea that I should make SLDoor a superclass of
new classes, one for each type of door. So I would have an
SLFlushDoor, an SLMonumentalDoor, and an SLPlankDoor for example,
all subclasses of SLDoor.
In this way, I can really separate out all kinds of code and
properties that are specific to a certain type of door, while
keeping in the superclass all the properties that are shared among
several or all of the types of door (I'm going to have categories to
handle drawing, material takeoff, pricing, etc for each door type).
So this is very attractive, but I keep worrying about how I would
change a door from one type to another if I utilize these
subclasses. Any ideas the best pattern to use? I can't figure out
how I would take an existing object of say SLFlushDoor and convert
it to an SLMonumentalDoor (and possibly back again) with anything
close to the ease that I currently do it with the doorType property
(but I shudder to think of all the if() statements I would have
strewn through all my code if I stick with this pattern.)
Thank you
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
