File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Patterns for hiding methods from third party classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Patterns for hiding methods from third party classes" Watch "Patterns for hiding methods from third party classes" New topic
Author

Patterns for hiding methods from third party classes

Jim Akmer
Ranch Hand

Joined: Jul 06, 2010
Posts: 104
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!
Jeroen K.
Greenhorn

Joined: Aug 03, 2004
Posts: 2
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
Ran Pleasant
Ranch Hand

Joined: Jan 16, 2003
Posts: 75
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Patterns for hiding methods from third party classes