On Dec 30, 2005, at 12:09 PM, Carsten Ziegeler wrote:

Aren't you tired of implementing a service/dispose combo for each of
your components over and over again? Now, actually, I am. Big time.

If you look at several of our components, they do something like this:

class MyComponent implements SOMETHING, ThreadSafe, Disposable,
Serviceable {
protected ClassA compA;
protected ClassB compB;
protected ServiceManager m;

public void service(ServiceManager m) {
  this.m = m;
  compA = (ClassA)m.lookup(ClassA.ROLE);
  compB = (ClassB)m.lookup(ClassB.ROLE);
}
public void dispose() {
  if ( m != null ) {
    m.release(compA);
    m.release(compB);
  }
}

Way too much code me thinks. So what about:

Come on! how many components do you write a day that 10 lines and 184 characters is too much? Sure less code and fewer interfaces are good things in general and I don't mind switching to constructor injection but give me a better reason than you want to write less code.


class MyComponent implements SOMETHING, ThreadSafe {
  protected final ClassA compA;
  protected final ClassB compB;

  public MyComponent(ClassA a, ClassB b) {
    compA = a;
    compB = b;
  }
}

We could simply add constructor injection: if the implementation does
not provide a default constructor, the available constructor is called
using reflection and the components are injected on construction of the
object - no need to configure something in any xml configuration file.
Implementing this is easy - I did this already years ago for Fortress.

But I think it can even get easier:
1. Let's just assume that every component is ThreadSafe - unless
otherwise stated - no need to declare the interface anymore. I think
apart from the interpreter most components are threadsafe or poolable
anyway.

I don't like assumptions like this. I see deadlocks in your future.


2. Let's remove support for pooled components - yes, seriously. Fiddling
with the pool sizes is really annoying. We have a working factory
approach for sitemap components, so why not simply use it overall? And
rewriting the remaining pooled components shouldn't be that hard. (I now
that we are proxying pooled components to simplify the lookup, but you
still have to configure pool sizes).


I make extensive use of the factory pattern and in some instances my factories use pools. Just because you use factories does not mean you can eliminate pooling. Now if you'd like to implement self monitoring pooling that tunes itself I think we'll all be happy.

My final idea is to use even more magic (but it might be too much magic?):

class MyComponent implements SOMETHING {
  protected final ClassA component_A;
  protected final ClassB component_B;
}
When the component is instantiated all instance variables prefixed with "component_" are setup using some injection mechanism - or perhaps using
annotations?

Now, in the end I really want to write less code :)

sounds lazy to me, but then again I don't want to write any code I just want to think of something and have it work. :-)


Glen Ezkovich
HardBop Consulting
glen at hard-bop.com



A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow