A couple of days ago a young intelligent man walked into my office with a design problem
on hand. He
said he decided to use SRP (Single Responsibility Principle) and so has separated
each concern into
separate classes. The result, he had about eight classes to solve that problem. He
wanted to know if
he's in the right direction.
I truly believe that agile development will become a mere act of code hacking if we
ignore good design
principles.
While SRP, DRY (Don't Repeat Yourself), OCP (Open Closed Principle), LSP (Liskov's
Substitution
Principle), and other principles with TLAs (Three Letter Acronyms) have been very
useful, the challenge
is figuring out if they are applicable. We need to figure out if we are using the
principles at the right time
and for the right reason.
In this particular instance, the bright programmer had taken the time to learn the
concepts and principles
as he was genuinely eager to learn designing. However, he was struggling to find if
he is doing things
right (that is key to learning?seeking feedback to see if we have things right).
The challenge in this case is while SRP is a good principle to use, learning what
that concern separation
is not easy. We discussed if the way he had separated the concerns actually made the
code more
cohesive, or less. In a few minutes, he was beginning to see that the separation of
the concern may not
be as clear cut as he had thought. We eliminated a number of classes. Then we discussed
about the
possibility of extensibility (based on what all this application should do) and figured
that introducing an
interface may be useful. We then set out to throw in some code to try out a few concepts
we discussed.
That is the beauty of design. It is hard to do it as the design greatly differs based
on the perspective.
That is one of the reasons why I think designing in isolation is a terrible idea.
How do we learn good design? Are there books and articles on the topic? Yes there
are and we should
certainly take time to read them first. However, the best way to learn design is to
do it and to do it with
someone. If you are working on a design (and you are if you?re writing any form of
code), then seek
some input from a colleague you respect. You will find that this becomes a learning
experience for both
of you. And, the design will evolve to benefits from the right use of good design
principles.
