Hi Im on holiday at the moment reurning 1 july. What you say sounds sensible but I cant check right now.
Bob On 17/06/07, Tom Morris <[EMAIL PROTECTED]> wrote:
Without understanding more about the cycle that you are trying to break, it's hard to give a good recommendation. From a casual look, it appears that everything that MemberList depends on is also depended on by Project which is the consumer of MemberList, so it's not clear that removing this class will improve things. Presuming that removing this dependency would help, you could make your proposal a little more generic by implementing a PriorityCategoryList and have the various member types implement a PriorityCategoryMember with the method getListPriority() or something similar. This would keep it from being coupled with the ProjectMember interface. If you do decide to reimplement, I hope the new implementation will have more Javadoc. The current implementation doesn't even have a class description. Makes it a little tough to figure out exactly what contract it's meant to guarantee! Tom > -----Original Message----- > From: Michiel van der Wulp [mailto:[EMAIL PROTECTED] > Sent: Saturday, June 16, 2007 12:29 PM > To: [email protected] > Subject: [argouml-dev] MemberList class: make a real List, to > remove dependency > > > Hi Bob, et al., > > My purpose is to detangle circular dependencies, in this case in the > org.argouml.kernel package (Project,...). > This package contains the MemberList class, which depends on > org.argouml.uml - and I want to remove this dependency. > > Although the MemberList implements the List interface, and it > keeps track of > ProjectMembers, they are not kept in a List. > Would it not be better to refactor this class, to make use of > a real List > (ArrayList)? > That would mean that we can remove the dependency on the > org.argouml.uml > package. > > In issue 2979, Bob wrote: > <A am grouping project members into 3 main categories, model, > diagram and > other. > > The purpose of these categories is to make sure that members > are read and written in the correct order. all models must be > read before diagrams, > diagrams > must be read before todo items.>These categories can be > implemented by > making the ProjectMember have a enumerated "category" > attribute LOAD_FIRST, > LOAD_LAST, NEUTRAL. > > Any thoughts? > Can I go ahead? > > Regards, > Michiel --------------------------------------------------------------------- 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]
