I am trying to refactor a class that has lot of redundant methods.
The original purpose of the class is to create object of class A and set its attributes; All the attributes have static values except one attribute; this attribute represents different types of classes/objects example -->(Order or Shipment) based on user request. These different classes are created by different factories (OrderObjectFactory or ShipmentObjectFactory) that DO NOT need refactoring.
The reasons for refactoring as follows: 1) To remove redundancy. Currently the class has grown over time and has methods that have duplicate code for each user request of creating an object having Order/Shipment/XX/YY/ZZ object as an attibute.
2) A need to create more types of classes (like wkorder/invoice) will grow in the future. Thus need to accomodate this change.
I started exploring the creational patterns like Factory Method and Abstract factory patterns. So far I tried to separate the changing part from the unchanging part in my class. Changing part being --> calling Order or Shipment object factory to create Order/Shipment objects and setting their attibutes.
For the changing part, should I use abstract factory pattern or factory method patten??? As far as I understand the abstract factory pattern defintion, it might not be useful in my case as this pattern's intent is to create a family of objects (In my case, I set only one attribute of class A with a fully populated Order/Shipment object based on user request).
My questions are: 1) Is abstract factory pattern suitable for the above scenario OR are there any suitable creational patterns?
2) Is Sping context based injection of the Order/ShipmentobjectFactory OR setting the attributes of the Order/Shipment objects recommended along with/without the creational patterns usage?
I would appreciate code/skeleton snippets for any of your recommendations.
Thanks in advance for your valuable time and input.
Take tiny steps. Collapse that duplicate code into shared methods first. Then you can see if it looks like it belongs in another class (a factory perhaps) or not. It sounds like you don't want to change the public API or the results of the calls, so you can write a set of tests that should continue to pass as you make your changes. That will give you a lot more confidence to make changes one step at a time.
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