I'm looking for ideas on the best way to refactor this scenario (better design, minimal effort). Starting from the following example abstract class (actual has many more fields, methods and abstract methods) :
abstract class Car
{
private int manufactureYear;
// ... many more fields that are hard to clone
public Car(int manYear)
{
this.manufactureYear = manYear;
}
abstract public Color getColor();
abstract public int getNumCylinders();
}
There are so many child classes (say 100) that extend this class. These child classes are considered like 'specs' for the cars. Here are two examples :
class CarOne extends Car
{
private static Color COLOR = Color.Red;
private static int CYLINDERS = 4;
public CarOne(int manYear)
{
super(manYear);
}
public final Color getColor();
{
return COLOR;
}
public final int getNumCylinders()
{
return CYLINDERS;
}
}
class CarOneThousand extends Car
{
private static Color COLOR = Color.Black;
private static int CYLINDERS = 6;
public CarOneThousand(int manYear)
{
super(manYear);
}
public final Color getColor();
{
return COLOR;
}
public final int getNumCylinders()
{
return CYLINDERS;
}
}
During runtime car objects get instantiated and used:
CarOne carObject = new CarOne(2009);
carObject.getColor();
carObject.getNumCylinders();
However, after getting some external data, I discover that the car was repainted and the engine changed. The new specs for the car become:
class ModCar extends Car
{
private static Color COLOR = Color.Blue;
private static int numCylinders = 8;
public ModCar (int manYear)
{
super(manYear);
}
public final Color getColor();
{
return COLOR;
}
public final int getNumCylinders()
{
return numCylinders;
}
}
So really need to "apply" these specs to the new carObject
without modifying existing fields such as manufactureDate
. The problem is how to minimize the code of changes to those 100+ child classes (preferably leave them untouched) while being able to update the carObject
during runtime.
N.B. I was given to work on this code so I didn't write it in this condition to begin with.
I'd also recommend taking a look at the Builder Pattern if you have cases (or entire groups of classes) which have complicated construction logic, especially if some fields are required in some Cars, and different sets of fields are required in others.
Based on the description and example, you are using inheritance inappropriately. It looks like you are creating many classes where you should be using a single class and many object instances. If this is true, you also don't need a design pattern to solve the problem. Without further clarification of the problem, this should suffice:
Example usages:
If you want to minimize changes, you could use my refactored Car class from above, and then clean up the child classes so they leverage it. Something like:
Since there is in fact a base class, my guess is that 99% of the code does not reference the concrete car classes (only the base class), so you should be able to change things fairly easily. Of course, hard to say without seeing the real code.
It depends on how much control you have over the code that creates these objects. I'm going to assume that this design exists for a reason that was kind of lost in the car example, but if the objects are created by calling new, then there is little you can do other than change them, although you could use the rest of this answer to suggest a more flexible way to change them.
If you can control their creation, then a factory that uses composition and returns a different kind of car object that overrides the specific parameters you care about and calls the original for the rest would allow you to affect your changes on a specific instance without changing all of the original classes. Something like:
Then inside that makeCar method, you can decide whether or not to return a CarOne object, or a composite implementation:
Your subclasses do not provide different behavior only different data.
Hence you should not use different subclasses only different arguments.
I would suggest add a "getCar" method to your base case and use it as an a factory method.
Add the Color and Cylinder properties and load them from ... anywhere it suits your needs, it may be a database, a properties file, a mock object, from the internet, from a cosmic place ... etc.
Before:
After:
So instead of create a new car directly you would get it from the getCar method:
I wouldn't recommend you to make your car "mutable" for it may bring subtle undesired side effects ( that's why I mark the attributes as final ) . So if you need to "modify" you car, you better assign new attributes:
Additionally you may even map the whole car so you only use one instance.
By doing this you don't have to add setters to your code. The only thing you have to do would be search and replace
For
And the rest of the code should run without changes.