Delegate Pattern?!? or memory leak?

[Wendy Wise]

I just inherited some code that is attempting to use the delegate pattern, I think. The Action classes call a delegator class, which calls a class that does the work. Here is the problem:
Each of the 14 action classes call the business delegator by using
"class name = new class();"
"whatIneed = name.doSomething(parameter);"
My 'delegator' class does the same thing--it creates another instance of the class to do the work.
That's it. Now if I'm doing that from 14 different classes, aren't I leaving all those 'delegate' objects out in never land waiting to get cleaned up? If so, what should I do? Should I create a single instance of the delegate classes?

[Frank Carver]

This certainly seems an unusual usage, although it's possible that there is code in the constructors which initialises some sort of time-sensitive or global-context-sensitive information in the constructed object. That would break the commonly accepted contract for a constructor, though, so if your system does that you probably have much bigger problems than a few objects waiting to be garbage collected.
Most systems I've seen which delegate method calls do so by either constructing or passing in the object to delegate to into a constructor:

class Whatever
{
 private Thing thing;
 
 public Whatever(Thing thing)
 {
   this.thing = thing;
 }
 
 public Whatever()
 {
  this(new Thing());
 }
 
 public void doSomething()
 {
   thing.doSomething();
 }
}

Do you have any idea why the code you are working on was written the way it was?

[Wendy Wise]

I think the people coding it wanted to use patterns, but didn't really understand what they are or how to use them. I need to figure out a way to fix it. The bottom line seems to be that each time I need an action class to do something, it instantiates the delegate, which instantiates a new business object. ALL the business code resides in ONE business object, so why should I instantiate 14+ of them?!? But how to refactor this is what is eluding me...

[Lasse Koskela]

The memory is leaked only if you leave a reference to those created objects somewhere. Usually this only happens with some sort of mapping structures, and based on what you said, I don't think your case involves a memory leak.
Furthermore, because it sounds like the delegator object has no significance as it is, I'd just rip it off. It's a smell. If it's needed later, it's easy to put back in.

[Wendy Wise]

I think they wanted the delegator in so they could change the back end to EJBs or something later without having to alter the front end at all. They anticipate having new developers on the front and more experienced in the back...

[Mahesh Chalil]

I would say, BusinessDelegate plus Command Pattern (Command Handler Factory and Command Objects) should be a good candidate to separate the client tier from the ejb tier(middle tier). As it is a best practice to do so, I would go for it. After that, it is not going to create any much -ve impact on the overall system.