Berin, thanks very much for this reply. It has helped clarify my thinking a lot. The idea of making the system harder to understand by circumventing standard java practise is something a colleague mentioned to me and which your comments have strenghtened. I'll keep digging.
Thanks again, Mike. ----- Original Message ----- From: "Berin Loritsch" <[EMAIL PROTECTED]> To: "'Avalon Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, January 14, 2003 9:16 PM Subject: RE: Question: _really_ inverting control > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
