On Fri, Oct 1, 2010 at 4:19 AM, Remco Poelstra <re...@beryllium.net> 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 <re...@beryllium.net> 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 (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