Question about seperating interfaces for clients

From: Ken (kk_oop_at_yahoo.com)
Date: 06/24/04 

Date: 23 Jun 2004 19:42:50 -0700

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?

Thanks,

Ken

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: 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)
  • Re: Message-based vs. method-based interaction [was: Re: LSP and subtype]
    ... interface is always the method signature. ... We can name it for the owner context of what it does or we can name it for the client context, but we can't do both. ... overlaying some sort of developer structure on the 3GL syntax. ... Such separation is impossible to do with pure 3GL language syntax. ...
    (comp.object)