cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 19:27:36 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org] 
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > 
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > 
> > > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > > 
>
> 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.

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.

> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message