Re: Question about seperating interfaces for clients

From: Universe (universe_at_tAkEcovadOuT.net)
Date: 06/24/04 

Date: Thu, 24 Jun 2004 00:50:13 -0400

kk_oop@yahoo.com (Ken) wrote:

> Hi.
>
> I have a class used by many clients. I want to tailor the interface
> for each client. I figure there are two ways to do this:
>
> 1- Make a wrapper to be used by each client. The wrapper would only
> make visible those methods the client needs. Each of its methods
> would delegate behavior to the equivelent method in the wrapped object
> (ie, the adapter pattern).
>
> 2- Have the class "implement" an interface for each client. A
> client's interface would only include the methods it needs.
>
> Option 2 seems simpler, but it creates a dependency between the
> implementation class and its various clients. However, in option 1,
> you need to write the delegation code. So normally, I lean to option
> 2.
>
> However, I have a situation where this class is used by classes in
> several distributed components. In this case I'm thinking that option
> 1 is better to avoid making not just a class--but an entire component
> dependent on a seperate client component.
>
> Any thoughts?

Implement the server objects like COM, where the object has multiple
interfaces and clients use a pointer to the interface they use. A
simple start with C++ would be use MI to incorporate each interface
into a single server class. A client uses a pointer to the interface
of interest, and thus does not see the other interfaces.

Not sure how changes to specific interface data (probably best
avoided), specific interface method signature, or specific interface
method count affects client not holding a pointer to that interface
would have to re-compile, and re-link. With COM it's unnecessary.
These are the good points of COM overlooked by many XP'ers whom
disdain COM.

Elliott 

-- 
It's ludicrous to say "OO is.." and not to have the term *objects*
somehow central, front and center in the definition.  As for example:
OO - a means for reducing complexity by viewing domains and creating
programs with the object as the core granule of abstraction.
Modelling objects, and with multiple objects, their collaboration is
key to conceptualizing and managing domains and programs.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Relevant Pages

  • Re: What doesnt lend itself to OO?
    ... >>server is a pure data transfer interface. ... essentially exposing the client or service implementation. ... >>paradigms can be abstracted just like any other problem space in an OO ...
    (comp.object)
  • Re: Text terminal rendering design
    ... free to give it any object that satisfies that interface. ... giving it a real facade object if I choose. ... Facade to avoid touching the client. ... completely incompatible with this subsystem interface. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... Entity has no encapsulation and no real methods, but the great thing about it is that its public interface will never have to change during maintenance. ... Assuming there is at most only one Property instance for each property type, then the R1 collection class would own the smarts for finding the right one. ... However, I would point out that the client of the getter is someone who needs to collaborate with a specific Property, not the Entity itself. ... The second line generates a message to the Property for the collaboration. ...
    (comp.object)
  • Re: COM, returned handles, and memory management
    ... how do I pass "an object" across a COM interface? ... > handle (e.g. an interface pointer). ... The client has not done anything with the ... >> RDeW ...
    (microsoft.public.vc.atl)
  • Re: Text terminal rendering design
    ... Which is exactly what would happen in your case when the interface of the implementation object changes. ... But then you need a new object to own the actual responsibility within the subsystem implementation. ... I can pop in a facade in a completely painless manner without being forced to rename or kludge anything. ... Facade to avoid touching the client. ...
    (comp.object)