The moose likes OO, Patterns, UML and Refactoring and the fly likes Is the a known anti pattern? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is the a known anti pattern?" Watch "Is the a known anti pattern?" New topic

Is the a known anti pattern?

Ramesh Chandran

Joined: Feb 26, 2007
Posts: 4
I am working on a project that contains a lot of preexisting code. I see one particular pattern used all across the code base and that is driving me crazy. Here is an example:

1. In the constructor of a service class, it creates an the object of another class that implements an algorithm and initializes that object.
2. Another method of this service class takes in the actual data upon which the algorithm has to operate. This method uses the previously initialized object and calls the functional method on it passing in the data.

The code is actually hundreds of lines but I have compressed it to illustrate the general idea. The problem that I face is while debugging.

For example, there is a exception while persisting the amortizations and I need to find out what is wrong. It could be because of the initialization parameters given while constructing the Amortizer or it something is being incorrectly computed in the compute method. Since Amortizer is constructed well in advanced and in a different thread, it is very difficult to find how were the parameters that were used to create Amortizer created. Similarly, since the compute method computes the whole set before persist is attempted, it is not possible to stop the debugger to check the computation for the case which causes persist to fail later.

So what I have to do is, first figure out which persist failed and get its id. Now put an if condition in the compute method:
if(id="the one that fails in persist"){
sout("..."); put a break point here

and run the damn thing again so that it would wait at that point where it starts computing for the problematic id and i can inspect the parameters.

I imagine it would be a lot simpler to debug if it were coded like this

So basically, what I am getting at is :
1. I am not liking member variables too much. They increase the distance between their creation time and their usage time. This becomes very confusing.
2. I don't like the pattern where you initialize an object separately outside of a constructor using multiple setter or even using an initializer method.
3. I would prefer passing as many method parameters as possible in main business method instead of setting them using multiple methods and then calling the business method.

Am I thinking right? Or the code that I have is actually well written and it is me who is thinking wrong? Is there is a name for this pattern?

thank you!
Junilu Lacar

Joined: Feb 26, 2001
Posts: 4445

Your description "another class that implements an algorithm" actually suggests the Strategy pattern.

Two other patterns come to mind to help improve your current design: 1) Builder and 2) Parameter Object

As with everything, member attributes can be used properly or improperly. It seems to me that the difficulty you are experiencing is because of improper use of member attributes, not any inherent problem with member attributes per se. However, passing many parameters to a method can itself be problematic. When you pass in three or more parameters, your code becomes more difficult to maintain and it becomes more fragile/brittle in the face of change. This is where the Parameter Object comes in.

Your suggested code looks fine to me, except for the multiple parameters. If it were me, I would use a Builder to create a Parameter Object and then pass that to the Amortizer.compute method.

Junilu - [How to Ask Questions] [How to Answer Questions]
Junilu Lacar

Joined: Feb 26, 2001
Posts: 4445

BTW, here's more information about the "too many parameters" problem: http://c2.com/cgi/wiki?TooManyParameters

There's even an anti-pattern associated with too many parameters: http://c2.com/cgi/wiki?MagicContainer
Ramesh Chandran

Joined: Feb 26, 2007
Posts: 4
Thank you, Junilu. That was helpful.
I agree. Here's the link: http://aspose.com/file-tools
subject: Is the a known anti pattern?
Similar Threads
Which implementation is better: Calling methods by several arguments or encapsulating in an object?
Co-dependent Classes
Generics - need help