I'm not exactly familiar with the internal workings here, but from the names of these classes and what you are saying, are we just trying to order some objects in a collection of some sort? And, this collection needs to be able to maintain the proper ordering as "things" are inserted into it? Then, why can't you use a java.util.SortedSet along with some Comparator implementations? Is there some weird requirement here that I'm missing?
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, July 12, 2004 10:00 AM To: [email protected] Subject: leveraging Orderer 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
