Re: Best pattern for similar objects with differences
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
Re: Best pattern for similar objects with differences
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 SLFlushDoor and convert it to an SLMonumentalDoor Do you need to change the type of an instance? Or can you replace it with a new instance of the new type? I don't know the details of your model, but the latter seems cleaner, and works well with subclassing. For example, if you need to convert to SLMonumentalDoor, you can add a method to SLDoor: - (SLMonumentalDoor*) asMonumentalDoor; which creates a new instance. (SLMonumentalDoor can override this to return self, of course.) —Jens___ 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
Re: Best pattern for similar objects with differences
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 doors. To be clear, you have created a door _class_ called "SLDoor" (or so I assume). 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.) Well, the first thing is to be sure that you really want to enable the user to change the door type. Does it make sense? What does it mean to change the door type. What happens to the properties that were appropriate for the old door type but aren't for the new door type? What values do you use for the properties of the new door type which weren't relevant for the old type? Etc. Can this be better modeled by creating a new door object of the new type, initializing it with some of the properties of the old door object, and then releasing the old door object? You would also replace the old door object with the new one in any collections. If none of that helps, then you can divide the representation of a door into two classes. Basically, you end up modeling a door type not with a name or numeric code value, but with a full-fledged object. So, your doorType property becomes a pointer to an instance of some SLDoorType class, or rather a type-specific subclass of SLDoorType. Any type-specific properties and behaviors would be implemented in that class. Some SLDoor methods might be implemented by invoking methods on the doorType object. In many cases, clients of SLDoor would directly reference, for example, door.doorType.typeSpecificProperty. When it comes time to change the type of a door, you replace the doorType object with a new object representing the new type. If appropriate, you can initialize the new door-type object with that subset of properties which it shares with the old door-type object. Accessing type-specific properties through the doorType property still presents a problem. Since the doorType property is statically typed as SLDoorType, which is a generic abstract base class of a hierarchy of door type classes, the compiler will complain if you attempt to access type-specific properties using accessors (because the generic SLDoorType class doesn't implement the type-specific properties). The Objective-C 2.0 dot syntax is just an alternative way to write accessor calls, so that runs into the same problem. You can solve this by accessing type-specific properties using Key-Value Coding. If you're using Bindings, then that already is based on KVC. Since KVC relies on the actual dynamic type of the door-type object, you don't have problems with the compiler complaining that the static type of doorType doesn't support those properties. So, assuming that "door" is an instance of SLDoor, you might have code which looks like [door.doorType valueForKey:@"someTypeSpecificProperty"] or [door.doorType setValue:someValue forKey:@"someTypeSpecificProperty"]. Now, what happens if there's an attempt to access a type-specific property when the door is not of that type? Well, ideally, you'd avoid that situation. You should carefully examine cases where you think you need to do that to see if they can't be better implemented by pushing responsibilities into the type-specific door-type class. So, if you have a method on SLDoor to compute the cost of a door, and the cost depends on the door typ
Re: Best pattern for similar objects with differences
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, which is what you typically want from an ordering app. Or you could make your app more domain-specific, which might be useful if you were making a computer-aided door design app. All of these things are, strictly speaking, general software engineering questions that fall outside the realm of Cocoa. There are, however, certain Cocoa-related implications: for example, a dumb container for dumb objects is very hard to make a custom interface for. This bit me on a radio automation system project a while back. I started out with an app that could hold music tracks with any arbitrary tags, under the assumption that the user would create tags to organize the library as they see fit . A song might wind up tagged "Mellow", "Country/Western", and "Male/Female Duet". All these tags lived in the same namespace, and I couldn't offer an interface to control that, much less do all the KVO niceties I wanted to do to get smart groups, filtering, and other features. So I decided to push more domain knowledge into my app, making it aware that songs could have mood, genre, tempo, vocalists, etc. This made the developer *and* user experience much better at the expense of some flexibility. If you look hard enough you see this tradeoff appear time and time again, often resulting in differentiation among competitors. It all depends on your use cases. --Kyle Sluder ___ 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
Best pattern for similar objects with differences
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
