Design Patterns Explained

Chapter 1 The Object-Oriented Paradigm 7
This does not mean you and I can give up on gathering good
requirements. It does mean that we must write our code to accommodate
change. It also means we should stop beating ourselves up
(or our customers, for that matter) for things that will naturally
occur.
Change happens! Deal with it.
In all but the simplest cases, requirements will always
change, no matter how well we do the initial analysis!
Rather than complaining about changing requirements, we
should change the development process so that we can
address change more effectively.
Dealing with Changes:
Using Functional Decomposition
Look a little closer at the problem of displaying shapes. How can I
write the code so that it is easier to handle shifting requirements?
Rather than writing one large function, I could make it more
modular.
For example, in Step 4c on page 4, where I “Call appropriate function
that will display shape, giving it the shape’s location,” I could write a
module like that shown in Example 1-1.
Example 1-1 Using Modularity to Contain Variation
function: display shape
input: type of shape, description of shape
action:
switch (type of shape)
case square: put display function for square here
case circle: put display function for circle here
Using modularity to
contain variation