classes/inheritance, how do I handle special cases that require more change

Question

I often find myself in this situation where I have a base class that does a lot of graphics. There are, for example, three strings that are positioned top, middle, bottom of an element. Like a scale or something. Now for every type of scale I make a new class that inherits the base class and simple sets the three strings and everything is fine. But often there is ONE single case, where I need four strings.

Sure, I could just override the method and recalculate for four, BUT if the calculations are based on a lot of offsets etc I would always have to take a look at how the base class does it in the first place and then copy-paste the entire calculation and do it for one more string. This means that every time the base calculation changes, I would need to copy-paste again etc.

On the other hand I could write the base class so super flexible that every tiny step can be overridden and subclasses can do everything they want with ease. But this requires way more work on the base class for ONE special case out of 20.

So either it's more workload in the beginning or the risk of missing a copy paste.

Often I don't even know what will come and you can't write a baseclass that is all-flexible and no one has the time to do so. So overriding and copy-pasting seems the best way to do so, but it still seems way too risky.

How should I approach this? I am looking for solutions that are practical, not a schoolbook approach that is too time consuming in a real work life.

(I mainly work with Java)

Edit: To get a bit away from my example, which is really just an example. Let's say i have a class and 20 subclasses and they work. Now along comes a new subclass that needs ONE thing completely different and just can't use the base classes method. If i override i have to copy paste the entire method and adapt it. If i change anything about the method, then i will have to change 20 classes that are already working fine.

"Do it from the start" works with one method, but what if 10 or more methods could be the cause for trouble. I can't write the base class in a way that for every method a variable-method-class can be used. I could, but that's what i meant above with "extreme workload at the beginning"

Answer 1

Another option might be to extract the algorithms in a class that implements an interface or abstract class. Then the calculation can then be very specific to the layout needed. For 19 of the cases pass In a reference to algorithm 1, for the other pass in a reference to algorithm 2. This allows your base class to remain lighter and still allow for the flexibility of having specifics.

Another plus is that if another layout comes along you can add another algorithm 3 class for that case. All while leaving the original base class without all the logic to determine which algorithm to use.

Also if there are methods that are shared you can have algorithm 2 extend algorithm 1 and just modify the methods that are needed.

I suppose theres also the option then of changing the algorithm class thats referenced at run time and swapping out how the layout gets generated, might be helpful.

Where do you decide what algorithm to pass in? Probably when the scale classes are instantiated.

Answer 2

Your first example sounds like it could be solved by designing things always with "n elements" in mind instead of having individual derived classes for one, two and three strings. Having just one class where the list of strings is a parameter which can be of arbitrary length n will probably reduce some duplicate code in your already existing cases, and eliminiate the need for using inheritance at all.

Your second example is more abstract, so it is hard to give you any good advice without seeing the real case. When there are already working 20 subclasses, the fact you cannot easily add one more is often a code or design smell. Maybe the scope of your classes is too big, maybe there is too much inheritance involved, maybe there is something wrong with "case 21". Most of this problems can be solved by thinking twice about it (and sometimes the best option is to live with a pragmatic "duct tape" solution for case 21).

Answer 3

Edit: To get a bit away from my example, which is really just an example. Let's say i have a class and 20 subclasses and they work. Now along comes a new subclass that needs ONE thing completely different and just can't use the base classes method. If i override i have to copy paste the entire method and adapt it. If i change anything about the method, then i will have to change 20 classes that are already working fine.

The simplest solution may be to rename the existing method and adapt it so that it handles the new special case correctly.

Then create a new method with the old name, which acts as a wrapper to the renamed function, and provides exactly the same interface as before. That way all the existing code in other classes can carry on as before.

As an example, if your existing method takes three strings as parameters, but you need to handle four. Re-name that method, and add an optional fourth string. Create a new method with the old name that accepts three strings, as before, and which calls the re-named method with an extra blank string added on.

Answer 4

I know you don't want a "textbook" solution, but this is an ideal problem for the Strategy pattern.

http://en.wikipedia.org/wiki/Strategy_pattern

Implement behaviors for your different algorithms and use them in the classes that require them. This way if something new comes up, you won't have to change what you have, only add a new behavior.

If you don't want to make a big change in code, you can come up with a mixed solution:

• Extract the code of your current overridable method into a different class (this will be a behavior), and used it there (this will leave your current method as a sort of wrapper).
• Only override your method to call a different behavior.

This way you are making your code more readable, easier to maintain, your behaviors are reusable and are less likely to introduce bugs due to some code being uses somewhere else: you know where your behaviors are used.

Answer 5

The textbook answer to your question is to "use composition over inheritance".

Instead of copy-pasting like crazy or trying to overdesign the ultimate base class, make pieces that solve parts of the problem and put them together.

Using your example, a part that might make sense would be a function that takes a string length, font, etc. and calculates the size of an onscreen rectangle that would fit it. Another part might be a function that takes a list of rectangles to be stacked on top of each other, and figures out a visually pleasing way of arranging them. By putting the parts together, you can now calculate a layout for your strings easily, and there's no difficulty going from 3 strings to 4 strings (especially if you just make a list of the strings in the first place and don't worry about how many of them there are).

Oh, but now we have to support icons, too. No problem, just make a function that takes an icon and returns its rectangular size, then use the rectangle normally. Adding new stuff doesn't involve changing working code, you just add a new piece or use the existing pieces differently.