• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is the a known anti pattern?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you, Junilu. That was helpful.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic