This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I am supposed to refactor a Java class containing 1000 lines of of code in a single Method.
I know its a bad Design to hold 1000 line in a single Method.So please help me out figuring How well to refactor!
Comming to the responsibilities of the Method.
1.There is an Object HugeObject which contains 21 Objects of type java.util.Set and 20 variables of type string all with its Getter and Setter
2.The method Retrives each of the Set Object from the HugeObject.
3.Calls the Helper class to find whether Reconilation logic applies the Objects
logic to Reconile the HugeObject
5.Calls Helper class to Verify the contents of the immediate Objects of HugeObject.
This is the sample code for 1 child object.
6.The Process repeats for the all the Objects.
The Method is holding 2 responsibilities
1.Calling the Helper class to verification
2.Reconcilation of the Object.
Please suggest me a right way to refactory the above.
The first thing you can do is look for any duplicated logic. You said the process repeats for each child object. Is the code the same? If so, you can put it in a method and call it 21 times. If not, are any snippets of it the same.
Thanks for moving my post to this Forum.Actually not every sure where to Post.
All the 21 Objects are different ,So should I Hold 21 methods.There is a common Logic in the 21 Objects ,so I can move it to a different method and call from the 21 Objects code.
Thanks for pointing the duplicated logic point.
Can you please point out any other things i need to consider while refactoring.?
Michael Feathers book "Working Effectively with Legacy Code" has a chapter dedicated to working with large methods. You might want to see if you can get a copy of this.
The basic idea is to apply safe refactorings in the first instance, ones that you know wont break the code. Then get the code under test (you dont want to be breaking stuff as you work). Once, you have the tests in place you can start breaking down the dependencies further and encapsulating bits of common logic as you go along...
You want to look for opportunities to apply design patterns to remove duplicate code. E.g. Template Method.