Removing the dependency on Werkz (see issue HIVEMIND-6) mainly
encompassed rewriting oah.order.Orderer. While refactoring this class I
noticed that it is not related to (i.e. doesn't use) the oah.Orderable
interface. I think this could be redeemed by a further refactoring.
Also I was thinking if it would make sense to leverage Orderer by
providing it as a HiveMind service.
Orderer is currently used to order two kinds of objects in HiveMind:
SymbolSourceContribution and ServiceInterceptorContribution objects.
The former is a class implementing Orderable and the latter is an
interface *not* extending Orderable.
The interface of the Orderer class is given by the methods:
public void add(Object object, String name, String prereqs,
String postreqs);
public List getOrderedObjects();
This means a client can't directly pass Orderable instances to the
Orderer. Instead the details of the object is passed and Orderer then
uses a local object to encapsulate these details again.
IMO it would thus make sense to move the Orderable interface into the
oah.order package and use it as the single parameter to the add method
of Orderer. I.e.
public void add(Orderable object);
A benefit from this refactoring would be that the "intermediate"
non-public class ObjectOrdering could be dropped. Of course the client
ordering ServiceInterceptorContribution instances would have to use an
adapter (e.g. an anonymous class) to be compatible with the new
interface.
Splitting Orderer into Orderer and OrdererImpl would let us publish it
as a service.
Thoughts?
Cheers,
--knut
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
