Dr Heinz M. Kabutz – Java Design Patterns

Like so many programmers of my generation, I started coding in BASIC. After a short foray into Turbo Pascal, my university led me gently to C.

Professor MacGregor then introduced C++. His lectures were ramblings in a thick Glasgow accent with matching handwriting. Stroustrup’s writing became my bible.

All through my university education, I struggled to rid myself of the bad habits endowed by years of BASIC and C. Polymorphism? No, I used switch statements and multi-conditional ifs.

I was insanely productive through the generous application of CTRL+C and CTRL+V. Part of my masters was an editor for SDL, used for network protocols. My professor and I sold this to a company in France. They visited us at the University of Cape Town and liked my program. To make it perfect, they wanted a few changes. It only took me a few hours to finish everything they wanted.

IT WAS ONLY WHEN I STARTED WORKING THAT I DISCOVERED THAT EVERYTHING I HAD LEARNED ABOUT OBJECT-ORIENTATION WAS WRONG

I had used the same coding techniques from C and BASIC in my C++ code. The result were lots of switch statements distributed throughout my codebase. Whenever I had to add a new design element, I would have to find and change each switch statement in turn. If I forgot one, which happened a lot, then one feature would not work anymore. For example, if I didn’t change the switch for printing, then my new element would show on the screen, but not in the printout. Each time I added one element, I had to test each function in turn to make sure everything worked.

This type of coding behaviour might be ok when you’re the only one working on that code. But it doesn’t make for happy team mates.

At my first real job, my mentor handed me the GoF book and said: “Here, you have to read this.”

I did. Most of the patterns seemed somewhat familiar from my years of coding C++. I put it aside. What could I possibly learn?

A year later I heard Martin Fowler at a conference in Cape Town. He described “Design Patterns” as the most significant software development book of the decade.

I picked it up for a second read. Perhaps I had missed something? It all seemed obvious the first time.

I DID NOT UNDERSTAND A WORD ON THE SECOND READ

How was it possible that a year of coding experience had made me so stupid? Surely real-world coding should have the opposite effect, making me more valuable as a programmer?

Indeed, it had. But the first time I read the book, I did not have enough insight to understand its true value. Martin Fowler’s words had made me pick up the book for a second time that I had discarded as “completely obvious”.