Re: Changing classes
Re: Changing classes
- Subject: Re: Changing classes
- From: Quincey Morris <email@hidden>
- Date: Fri, 1 Oct 2010 10:31:41 -0700
On Oct 1, 2010, at 02:19, Remco Poelstra wrote:
> I'm representing network enabled amplifiers, some of which have multiple inputs, some not. Other have surveillance features build in, which others might not have.
> I'm not trying to simulate them, just representing them so I can communicate with them.
> I think I do not fully understand the difference you are trying to make between device and class behaviour. The amplifiers do a lot the same, but some responses might need another interpretation.
I'm saying that the behavior of you amplifier is to amplify, but that's not the behavior of your class.
Here's a (hypothetical) concrete example that might make my point clearer:
Let's say your amplifiers are of several types vary in just 2 ways:
1. They have different inputs.
2. They have different protocols for communicating the state of their inputs.
Does that mean you need a separate (sub)class for each amplifier class? Not necessarily. You might choose to represent your devices with instances of a single class that has properties for the number of inputs, and the communication protocol involved.
Each instance would communicate with its amplifier by consulting the communication protocol property and sending suitable messages. Using this protocol, it could then ask for all the input values, after consulting the number of inputs property to decide how many inputs to request.
The question you should ask yourself, I'd suggest, is this: What would prevent me from using a simple one-class design to represent my devices? If there's nothing to prevent you, then don't complicate the picture with subclasses. If you're not sure of the answer (which often happens during the application design phase), you can start with a simple design and see if it works or not. Don't be afraid of trying multiple approaches if your application doesn't fit a known design pattern.
_______________________________________________
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