Design Patterns, PHP, and Magento

In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides — via their publisher Addison-Wesley — released a book titled Design Patterns. This book describes 23 different approaches for

“simple and elegant solutions to specific problems in object-oriented software design”

This book has been a wild success and has, in many industries, created the template for what “professional software” should look like. This book is also why, in recent years, camps of PHP developers are grumbling about all those [darn] class files.

The Context of Design Patterns

The authors of Design Patterns were all experienced programmers. The myth of this book (more true than not) is all four programmers got together, looked at common problems they all faced while implementing “object oriented” systems, and came up with 23 design patterns as common solutions to these problems.

Remember though — the book was published in 1995. This means “object oriented programming” meant “using C++ instead of C”. These 23 patterns were a harness and bit to place over C++’s notoriously powerful and abstract feature set.

So why do we still talk about them today? In part because 1995 also saw the release of a little programming system called java. The engineers at Sun Microsystems wanted java to do a number of things — one of which was “Become the official standard for what object oriented programming meant”.

Early java systems programming, and the development of the language itself, was heavily influenced by the Design Patterns book. Sometimes because Design Patterns offered the right solution, other times because the culture and politics of object oriented programming expected to see Design Patterns like code, and developers and companies wouldn’t seriously consider anything that looked different.

Design Patterns and Education

Another reason for the success of the Design Patterns book is the higher education system. There’s a tension all college programs (at least in the US) face: The primary reason for higher education is to teach people to think deeply and widely about their chosen field of study, but colleges are also expected to prepare their students for the job market in any particular industry.

Computer Science programs feel this tension acutely. Computer Science is, at its heart, the study of base-2 mathematics. Computer Science programs, on the other hand, are (or were) heavily funded by giants like IBM, Microsoft, Apple and the like. These companies invest in colleges, expecting them to produce working programmers. (This has gotten more complicated since the mid-90s with offshoring and the rise of Venture Capital Inc.™, but that’s another story for another time).

Java was rapidly adopted by colleges and institutions as a compromise language that would allow them to teach deeper level computer science topics, while still preparing students for the middle and upper middle class jobs they and their parents expected after graduation.

Teaching Design Patterns — either explicitly or implicitly — became hugely popular. This fed into the book’s success, and the book’s success fed into teaching it in colleges. Teaching students Design Patterns forces them into all sorts of programming situations. It’s a fantastic tool for teaching students how to reason about their code, and (if taught in C++, or the java curriculum includes courses in the virtual machine) how the underlying data structures map on actual memory.

Design Patterns and Industry

As the 1990s progressed, universities are cranking out programmers who understand Java. Microsoft notices, and releases C Sharp (their java clone) in 2000. There is an abundant pool of talented programmers who think and write code in a Design Patterns style. Companies, hiring these young programmers, end up instituting a corporate style of programming that’s heavily Design Patterns influenced.

Smart people with a bit of vision notice this, and a cottage industry of how to apply these design patterns to corporate problems crop up. Books like Martin Fowler’s Patterns of Enterprise Application Architecture become influential.

If the original Design Patterns book could be summed up as

How a programmer can get C++ under control

This new wave of books could be summed up as

How to build your programs and be successful in a large corporate environment

A few things to remember about large corporate environments

• People with decision making power are separated from the people who do the work
• It’s very hard to say “No” to a person with decision making power without threatening your career growth
• There is a bias towards growing a team if it means stability
• Having one irreplaceable person is an unacceptable risk

For software to be successful in these large corporate environments, it should violate as few of these rules as possible. Because of this, corporate design patterns tend to split functionality in lots of very specific implementation classes, with a system that makes replacing those classes straightforward.

As an individual you might balk at a system with 500 plus class files and shiver at a refactoring effort — but in a corporate system with a team of 15 developers — that’s around 42 class files per developer, figure 2 days per class file, and instead of saying “No we can’t do that”, you can say “Yes, we can do that, but it will take three months”.

Design Patterns and You

So, does this mean you should adopt a Design Patterns style of programming? Or does it mean you should shun a Design Patterns style as awful?

To me, that’s the wrong question, and the wrong mindset. Similar questions that come to mind

Is it good to wear a raincoat?

Do I want to wear snowshoes?

Are animals dangerous?

Lacking context — those three questions are impossible to answer. Better questions might be “What’s the weather like today?”, or “Am I in a zoo? At a friend’s house? Or on a three day hike through Yosemite.”

It’s more useful to think of the Design Pattern style, the style that makes PHP developers grumble about all those darn class files, as a natural phenomenon of corporate run programming projects. If you encounter an executive at a company like Oracle, IBM, or eBay, they’re going to expect to see this sort of code.

In these environments, if you’re pushing for a simpler system like Laravel or Rails, you’re facing an uphill battle. Sometimes because the executive is fearful of something that doesn’t look like Java. Other times because the executive is wary of platforms under the control of an irreplaceable individual or small group of individuals. This is, from a purely technical aspect, incredibly lame. It’s also the price of admission into the corporate world.

So my advice? If you want to remain on the technology side of the fence, and want to successfully implement solutions in code, learn how to work with both the “way too abstract” corporate systems, as well as the simpler, more straight forward, but equally powerful systems. When you see some code that looks incredibly stupid — put yourself in the position of the person who implemented it. Most “stupid” things in programming were put there by smart people for a specific reason.

If you’re less draconian in your thinking about The Right™ sort of systems programming, you’ll be able to make the transition when a large corporate entity acquires your framework of choice and makes the inevitable corporate shift to more abstract code. You’ll also be prepared when that corporate entity spins off your framework of choice and those abstract corporate patterns hit the fan of the real world, and the framework’s forced to readjust towards more practical solutions.

The most important thing you can do to ensure a long life as a professional programmer isn’t developing attitudes like Design Patterns Forever, or Burn Those Classes to the Ground. It’s being able to adjust to, and understand, why things change, and why the women and men who make these systems make the choices they do. Keep your eyes on that year over year, and you’ll find smoother sailing through the choppy waters of a career in programming.