Re: Changing classes
Re: Changing classes
- Subject: Re: Changing classes
- From: Allen Ingling <email@hidden>
- Date: Fri, 1 Oct 2010 11:29:04 -0500
On Fri, Oct 1, 2010 at 4:19 AM, Remco Poelstra <email@hidden> wrote:
> I think I do not fully understand the difference you are trying to make
> between device and class behaviour.
I think what he means is: use a single class for representing all of your
amplifier types instead of one unique subclass per amplifier type. The type
of amplifier which a particular instance of a class represents would be
identified by an instance variable (an enumerated type would work here),
instead of by the subclass. Whether this is a desirable solution or not
would depend on what characteristics distinguish these amplifiers and their
degrees of similarity. If it is that that some amplifiers have subsets of
common functionality enabled then you are well off using that approach; Use
the same class for all amplifiers and use instance variables to track which
features are active on a particular amplifier. On the other hand, if the
amplifiers have disparate architectures such that method foo for amplifier
type X must do different work internally than method foo for amplifier type
Y, then polymorphism is your friend; Use different subclasses for different
amplifier types (or if very disparate, then different classes which conform
to a common protocol). The design philosophy at work here is that when a
method takes variant actions, it can be better to organize those variations
by putting them in different subclasses, instead of by conditional branching
from within the same class to different methods or by conditional branching
within a method.
I do not agree with my own earlier suggestion to consider class clusters.
But here are some other alternatives:
1. Do a depth-first probe of your amplifiers instead of a breadth-first
probe so that you can fully identify their characteristics before creating
an objects to represent them. Are you in a catch-22 here because the object
which probes the amplifier is the same as the object which represents it ?
2. Have the class which owns the amplifier object create and query a generic
amplifier object which probes a particular amplifier, then the owner class
releases that generic amplifier object and creates a more specific subclass
to replace it according to results returned by the initial generic probe
object. (same as Keary Suska's earlier suggestion)
3. Use a generic wrapper object which implements that probing functionality
and which itself creates and owns an instance of a subclass implementing
amplifier-type-specific methods. Clients of the amplifier object API treat
the wrapper objects as amplifier objects and the generic wrapper objects
forward calls to their amplifier-specific subclass. Essentially this is
the same as 2 but with with better modularity because you tidily isolate the
amplifier-specific object creation within the wrapper object. The messy
business of choosing the subclass would be opaque to the clients of your
amplifier object API. (See the "Objective-C Runtime Programming Guide"
section on forwarding.)
- Allen
On Fri, Oct 1, 2010 at 4:19 AM, Remco Poelstra <email@hidden> wrote:
> Op 30-9-2010 21:58, Quincey Morris schreef:
>
> It's not at all obvious that having your class(es) "represent" your
>> hardware is the right way to approach this.
>>
>> What are you actually trying to achieve? If the various kinds of
>> hardware are differentiated by their "properties", then a single
>> class encapsulating the possible properties (including a
>> specification of which properties are actually present for each
>> device) may be all that you need.
>>
>> You would only use a class hierarchy if the class has significant
>> shared *behavior*, plus behavior that is specific to each device
>> type. Note that I'm talking about class behavior, not device
>> behavior. The device behavior isn't relevant to the class behavior,
>> unless the class is a software simulation of the device.
>>
>
> Hi,
>
> Thanks for all answers! Seems there are a lot of possibilities solving such
> a simple thing :)
>
> 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. In the end, all
> communication is over a standard protocol for all amplifiers and I want the
> UITableview on my iPhone to show more or less (depending on capabilities of
> course) the same layout.
>
> Kind regards,
>
> Remco Poelstra
>
> _______________________________________________
>
>
_______________________________________________
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