• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Patterns for hiding methods from third party classes

 
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, can someone help in the following?
I have class Csystem that has a lot of methods and handlers


CSystem is a class that is essentially an interface for other developers of other components to my code. Some other developer will write his own version of class AListener (class A) and use Csystem in his code. Whenever an event occurs somewhere (e.g. a message in the network arrived) class B will pass the event to the event handlers of CSystem


My problem is that both class Dispatch (implemented by me) and class AListener "see" the same interface of CSystem. I would like the developers who implement the AListener to see a different view of CSystem and "see" and be able to use only methods that are public. I don't think that it is a good idea to see methods someone actually can not use (handlers are meaningful to be used only by dispatcher) Is there a pattern to achieve this?

Thanks!
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jim,

If you want an implementation class to have two 'faces', simply make it implement two interfaces. One to be used publicly, one to be used by your code. I don't think this is a pattern, it's just basic OOP use.

However.. I suspect the problem in your case is a modeling issue. Two responsibilities can be discerned: a Listener that knows how to handle events, and a Dispatcher that knows when to pass what event to which Listener. This is basically an Observer pattern.
I'd reconsider the necessity of CSystem here. Other developers would only need a Dispatcher instance and register their AListener implementation with it. Adding a CSystem to that programming model would only obscure it.

You can use CSystem for managing the Dispatcher instance and providing it to the client code. But still neither Dispatcher nor Listener would need to know anything about CSystem, removing the need for a 'split personality' of CSystem altogether.

Hope it's of any use.

Regards,
Jeroen
 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim Akmer

I would suggest learning Robert Martin's principles of object-oriented design. Especially take a look at the Interface Segregation Principle. You can find these principles online and in Robert Martin's book Agile Software Development.

Ran
 
reply
    Bookmark Topic Watch Topic
  • New Topic