> From: Mike Hogan [mailto:[EMAIL PROTECTED]] > > Hi, > > The system that I am currently working on is one vast prairie > on public > classes and methods. Anything can call anything else, and > usually does, > resulting in circular dependencies and all kinds of mess. > This is as much > my fault as anybody elses, but thats beside the point.
I myself am in the process of improving a big ball of mud that I inherited. It happens, but we need to be careful how we dig ourselves out of the pit. > If we take Avalon into use, we can move to a situation where > we can have > components collaborating together in a much more ordered > manner. But there > is still some possibility for a Component implemenation to > just go right > ahead and request any old component from the ComponentManager or to > instantiate any public class that is anywhere in the > classpath. What I have > in mind a total lock down along these lines. Keep in mind that containers like Merlin and Phoenix do not allow that to happen. You must explicitly declare the components upon which your component depends. As to the problem of just any class being instantiated, that is an issue that can be conveniently controlled using a SecurityManager. I don't think that the lock down is your best solution. > * The constructors for all the component implemenations are > private. There > are no constructors of scope greater than package protected. BAD idea. Anytime you mess with the language semantics, you mess with very well known concrete contracts. You will lose alot of users. > * The ComponentManager instantiates component instances > using reflection > and setAccessible(true) to bypass the private scoping Also a bad idea. Forcing the use of reflection illiminates more powerful solutions like generative programming. Also you are asking for security exceptions and more when Avalon is embedded in a larger context. > * When a Component requests an instance of another > component, it passes > itself to the ComponentManager as a parameter. The > ComponentManager checks > if the requesting component is permitted, as per a config > file, to use the > requested component before proceeding. So, component > relationships are made > explicit. You never need to pass in the component to achieve this. All you need is a container that provides a unique ComponentManager to each component. That unique ComponentManager will only permit access to the components specified in the component's meta data. Again, see Phoenix and Merlin for this capability. It will be part of Avalon's future. > * Components are implemented as much as possible in a single > package, which > all constituent classes having package protected scope. That is your perogative as a developer. You need to do what makes sense to do. > ANyway, I just wanted to hear what you thought about this, > and whether there > is any room for this kinda thing in Avalon, especially the > "privitization" > of constructors. Or whether the thing is plainly impractical or just > plainly unneeded - I have yet to prove the case either way. If you want to explore explicit scoping of what classes may access other classes, then I strongly suggest that you look at AspectJ. They provide a nice little tutorial on how to create development Aspects that only apply during the development phase. One of those tutorials includes locking access to a class or package to be accessed exclusively by another class or package. There are other solutions available that are less radical, and help to incrementally bring a rougue application into good design without throwing away the effort that is already there. I highly suggest exploring methods that do not alter well known and existing *language* level contracts, or force a particular implementation on a container. IOC works very well, and can allow a container to "sandbox" components easily. You do need to be careful though. When you are too strict too quickly, then you have a mountain of work to do immediately. I suggest attacking one concern at a time. That way you can slowly add shape to the big ball of mud, and eventually you will have your well designed application--without throwing away your current investment. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
