Hi!
> My question to you is: it would be a much better and cleaner design to
> have Rete look like this:
> ...
I do agree with you that your refactoring would lead to a cleaner design.
> But this would break ALL Java code that works with Jess. Should I
> compromise and put dozens of forwarding methods in Rete like
>
> public int run() { return m_theAgenda.run(); }
>
> or should we bite the bullet and do things correctly?
I don't quite agree that including forwarding/delegating methods in the Rete class is
a compromise or even incorrect. I guess you know the Facade design pattern used to
provide simple and/or convenient interfaces for complex systems. In principle, that's
what you'd do when including forwarding methods. The Rete class would be a facade
providing a convenient way of using a collection of Jess objects. It wouldn't prevent
anybody from getting the Agenda object and calling its methods directly, though.
Furthermore, delegation is a good reuse mechanism. It should sometimes be preferred
over inheritance. In some situations it's the only way of achieving reuse (at least in
Java). Larger components can be built as aggregates of smaller components by using
delegation. This doesn't hurt encapsulation or modularization.
Look at the Swing architecture as another example of components providing convenience
methods. Swing objects like JTable or JList (these are View-Controller in the
Model-View-Controller paradigm) have models. You can always call
viewObject.getModel().theModelMethod(). Usually, viewObject.theModelMethod() works,
too.
Greetings
Thomas
---------------------
Dipl.-Inform. Thomas Barnekow
Mobil: +49 (0) 172 / 7126018
E-Mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
