How to implement unstable behavior / requirement
The customer, as we know, is always right even when he returns on his steps, and he forces you to review / rewrite a behavior for a component that seemed clear.
But the worst has not yet arrived, because the user can ask to change that requirement again, or worse, put things back as they were before.
Fortunately, Object Orientation comes to your aid with one of the most important design principles.
“Identify aspects of application that vary and separate them from what stays the same.”
If you have a feature of your program that
- your client asks you to change several times
- or simply that it can have different behaviors based on different inputs
then it is necessary to extract it from the main context and create one or more components that implement these different versions / behaviors.
Don’t be fooled to use the inheritance! In this case, in fact, inheritance cannot help you because there is the risk of having unwanted behavior performed.
Even the interfaces may not be sufficient because it forces you to write methods that are not used or to write the same method several times, duplicating the code.
Solution
Create a set of classes for each feature that tends to vary, where each class represents a possible behavior
Of course this set of classes implements the same interface.
Furthermore, following the principle
“Program with Interface and not with implementation”
to implement “unstable requirement” you will refer this interface in the main system.
In this way your client can change his mind whenever he wants, and you will be ready to please him and, perhaps, become his best friend or psychologist …