Re: Best pattern for similar objects with differences
Re: Best pattern for similar objects with differences
- Subject: Re: Best pattern for similar objects with differences
- From: Kyle Sluder <email@hidden>
- Date: Wed, 4 Nov 2009 11:01:15 -0800
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 (email@hidden)
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:
This email sent to email@hidden