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 ent
On Nov 4, 2009, at 10:47 AM, Paul Bruneau wrote:
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 SLFlushD
On Nov 4, 2009, at 12:47 PM, Paul Bruneau wrote:
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 door
It kind of depends on what your app is doing with the doors. For
example, you might get away with having a single SLDoor class with a
dictionary of attributes, much like one might order a car based on
option codes. This makes your app highly flexible in the
configurations of data it can deal with
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 wh
