> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > > Hmm. What we have here is a bad design. Should the > > container make up for your poor design? Can you really get > > away with only three instances in a pool with a web > > environment? Honestly, there is nothing in Cocoon that does > > what you are talking about. > > Yes, it is bad design. It is more than that - it is horrible design. > > But admit one thing: It was not difficult to see that it was > utterly atrocious! > > I meant to use it to show a situation that may occur in a system. It > will > not be as clearly awful as the abomination I showed you, but *hidden* > in the code. I can show you more poor architecture: > > public void tailRecursive (int i) { > if (i < 100) { > mycomp = lookup (...); > tailRecursive (i + 1); > } > } > > Of course, the component should be passed in to the method. The point is > that you may have these patterns in your system on a much larger scale > *without knowing* it.
I do not (fully) agree with you here. In J2EE, it is common to have session EJBs working with JDBC connection. You obtain connection whenever you need it and return to the pool when you are done. If you to write Avalon application after this pattern, you will have several ThreadSafe components (session EJB) and one or more pools of JDBC connections. Every component's responsibility will be to lookup and return connection. What you are proposing is to pass this connection across all these components, and move the responsibility of connection management from component which uses it to the caller who might not be aware about it at all - and it should not, because caller does not need to know component's dependencies. Moreover, if component needs more then one component to work (and this is not the rare case), or different components need different connections/other components, you will end up with lots of arguments in every business interface (or Map filled with required components... why not just pass manager as an argument?) > You will suddenly experience massive slowdowns and not know what is > happening. After a few hours or days of going through code you realize > that > a certain method is being called multiple times. And that method does a > lookup. > > > You have something more than "I may want to implement this > > poor design some day" that we can discuss? > > As I said above, I tried to show you a pattern by distilling it > to a very short example. Apparently I failed so badly that you > thought I really advocated writing of such code. > > > Why not discourage bad design? > > Why not? Well, it depends on how that discouragement is done. > If designing your component poorly leads to YourCodeSucksErrors being > thrown all over the place (with correct line number and file info) the > moment you start the server, then I'm all for it. > > But if, when you do something that is completely correct within the > context of your component, but, in interaction with other parts of the > system that you may not know of, leads to sporadic and erratic behaviour > seemingly unrelated to your code - then that discouragement is not > helping anyone. I completely agree with this point. This will make it very difficult to write reusable components, and impossible to envision behavior of complex system. Vadim > > Now, a way to philisophically enforce the "do" vs. > > "represent" concept is to call the components by a new name: > > services. A service is a type of component that "does" > > something or performs a service. > > OK, got it. > > I disagree, but that is for another time. > > /LS --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
