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?
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.
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.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: Patterns for hiding methods from third party classes