Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes OO, Patterns, UML and Refactoring and the fly likes Handle situation where there can be Potential increase in the method parameters. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Handle situation where there can be Potential increase in the method parameters." Watch "Handle situation where there can be Potential increase in the method parameters." New topic
Author

Handle situation where there can be Potential increase in the method parameters.

Meghana Meduri
Greenhorn

Joined: Mar 29, 2006
Posts: 27
I am at a stage where I have to refactor my code to accomodate future changes without changing mehtod signatures.
I have like 10 methods that take about 5 method parameters.
Couple of these methods are called recursively.
And few are called from other methods.
The input parameters from one method are passed to other methods.
The role of the input parameters vary based on the method.

Example:
private void createElem(Element doc, String factor1, String factor2, String factorOwner){

runElem(factor1,factor2,factorOwner);
Element elem = getElem(factor1, factorOwner);
doc.addContent(elem);

}

private Element getElem(String factorOwner, String factor){

/*some mainframe rule is called with rule owner as factor owner*/
}

In the example, factors are like the input criteria to the rule engine and factorOwner will define which rule to run.
As it is obvious that based on the function, different rules need to be processed.

I see that there could be potential increase in the input criteria.
in which case, I don't want to change the method signature to take that new factor as the method parameter.

I thought of using a value object called Factors that holds all the input crtieria.
But the problem is with the recursive calls as the role of the factor depends on the method in which it is executing, I need to add logic to update this value object in each method and I cannot retain previous values else I need to create new value object each time, which can be a overhead.

Any Ideas how to refactor such code, where there can be potential increase in the mehtod parameters.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Meghana Meduri:

I need to add logic to update this value object in each method and I cannot retain previous values else I need to create new value object each time, which can be a overhead.

Don't prematurely constrain yourself to not creating intermediate objects - the overhead may be insignificant and you may be unnecessarily creating yourself grief.
Anyway. The solution may be to create multiple parameter objects (which implement the same interface(s)) that inherently "know" which factor value to return when they are "asked". In essence you would be moving the decision "which value to present" out of the calling function into the specific parameter object - and the preferred method would be polymorphism over conditionals (See Replace Conditional with Polymorphism). Example:

If you cannot resolve all the variations through polymorphism alone and you still feel the need to let the calling code steer which part of the complete parameter to expose to the called function then you can use inner classes and interfaces. Example:
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I have a flippant guideline that the only numbers I want to see in code are 0, 1 and infinity. That makes factor1 and factor2 jump out at me. What would be the cost - how many places would you change in the code - for 3 factors? Then in the next release for 4? Iterating some collection of factors now means you never have to think about the capacity again.

Is that the kind of thing you're thinking about?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Meghana Meduri
Greenhorn

Joined: Mar 29, 2006
Posts: 27
Thank you Peer Reynders,
I refactored my code using value objects.

Stan,
I can say that this project is coding while other team is analyzing the requirements. I guess 80% of them are done. based on which I designed this application. But as days pass by I see that every day new factor is being added to the current rules. So, I want to refactor current code to accomodate such factors.

And these factors need to be updated at eveyr place where rules are called.

The input to this application will be an XML document, which need to be converted into another xml document which confirms to the schema.

The following are some of the key processing points while conversion.
- Some of the child elements should be converted to buch of elements.
- Some of the child elements are required. But unfortunatly there is no schema to validate this i/p xml document.
- Some of the required elements may be empty, so, there will be an alternate xpath which can be used to fill in these empty elements.

All these are driven by rules engine written in mainframes.
So when each special scenario is processed, the factors/qualifiers to call these rule vary. One factor may act like a rule owner in one context and like a factor/qualifier in other context.

I really appreciate both your replys.

Thank you
Garrett Rowe
Ranch Hand

Joined: Jan 17, 2006
Posts: 1296
I have a flippant guideline that the only numbers I want to see in code are 0, 1 and infinity.
I would have to include 2 in that mix... well I guess I could code it as (1 + 1)


Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18989
    
    8

Originally posted by Stan James:
I have a flippant guideline that the only numbers I want to see in code are 0, 1 and infinity.
It's a widely-used guidline:

http://www.catb.org/jargon/html/Z/Zero-One-Infinity-Rule.html
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I have seen it other places, but I proudly claim to have "discovered" it independently in about 1980. I worked with a mainframe system that had the magic number "7" in almost every program, just because there were 7 lines available on the screen design when they listed all the products owned by one customer. I still wake up screaming some times.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Handle situation where there can be Potential increase in the method parameters.