tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: [OT] question regarding tomcat source code and dependencies
Date Fri, 07 Feb 2014 20:50:09 GMT
Hash: SHA256


On 2/6/14, 11:08 AM, Leo Donahue wrote:
> This question was spawned by two things:
> I'm reading a book on Dependency Injection The latest security
> announcement - reading the source for

Umm... ?

> Some reading material suggests that one use a simple factory
> pattern to move object creation dependencies to a different class.

Dependency Injection (or IoC, or any number of other names) is
different than using factories. It basically places the burden of
dependency-wiring on the DI framework and removes it entirely from the
"real" code.

Take the following example:

class SomeClass {
  public void someMethod()
    Fruit fruit = new Apple();;

That's pretty straightforward: the caller can call a method
(someMethod) and an apple is created and eaten (whatever that means).
If you want to say "well, I want to be able to eat any kind of fruit",
then you could change that into a factory:

class SomeClass {
  public void someMethod()
    Fruit fruit = FruitFactory.createFruit();;

That hasn't changed much. If you do alot of fruit-creation, and you
always use the factory, then you can switch from apples to bananas to
pears in one place and everyone is all eating the same thing. Great.
But that's not DI and it's not IoC. This is IoC:

class SomeClass {
  private Fruit _fruit;

  public Fruit getFruit() {
      return _fruit;

  public void setFruit(Fruit f) {
    _fruit = f;

  public void someMethod() {;

Then you tell the IoC container: "SomeClass requires some fruit.", and
then you either tell it exactly what fruit to use, or provide it with
some hints as to where to obtain fruits and it will wire-up the
relationships. The IoC container will create an instance of SomeClass,
fill it with fruit, and then you can call SomeMethod without ever
having to juggle the whole fruit situation at all.

> I see where the object dependencies that has,
> like FileItemIteratorImpl, just simply place those dependent
> classes in the same java source file.
> I don't see a problem with that approach, should I?

That's one way to do it. But you are talking about class design and
physical implementation, not simply class architecture and the logical
relationships between things. Inner classes are sometimes entirely
appropriate, and other times they are awkward to use, etc. For classes
expected to be used directly by client code, it's nicer for
documentation purposes to have them in separate classes (i.e. not
inner classes).

So... what does this all have to do with the recent security announcement?

Hope that helps,
- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message