Don't read Design Patterns

home

 

After you learn all about loops, arrays and so on it's natural to wonder about how we organize big programs. True, functions and classes are about organizing, but we need something more encompassing. A little searching leads to something called Design Patterns. They're certainly popular, but depressingly vague

This is a quick explanation of what they are, why you should ignore them, a very tiny review of Software Engineering, and finally a short explanation of each Design Pattern.

Very short version

Design Patterns are tricks to organize a very large program in a pure Object Oriented style. If you're having problems doing something, they won't help. It would be like getting stuck on a tax form and buying a file cabinet. If you're not trying to use a pure OOP style, Design Patterns will seem awkward (if you have to ask whether you're trying to use a pure Object Oriented style, you're not.)

I've found most people asking about Design Patterns really didn't realize there was more basic programing to learn: arrays and array tricks (and linked-lists and hash-tables - which are maps in C++ and dictionaries in C#.) Breaking things up into clean functions. Writing small classes with useful constructors and helper member functions; using classes as return values. Pointers and function pointers. 2D arrays and large arrays of classes of arrays of classes. Recursion. A first year Com Sci book will cover most of these.

Short Version

From about 1995 to 2000 the internet went public and grew into the first dot-com boom. There was a huge demand for web Java programmers: Object Oriented Programming was the new promising style, and Java was the hot new OOP language.

Meanwhile, in 1994, a book was written named "Design Patterns: elements of reusable object oriented software." It was two dozen programming tricks renamed and rewritten in Object Oriented style. Nothing special, but nothing wrong with it either.

The flood of new internet Java coders were mostly self-taught and didn't feel connected to traditional computer science. They were looking for guidance and that book was exactly what they wanted. Pretty soon employees were using the official Design Pattern names in meetings. More importantly, overwhelmed managers realized they could ask Design Pattern questions during performance reviews and for job interviews. At that point, whether they worked or not, Design Patterns were a part of the corporate Java world (and now its copy, C#.)

Design Patterns today are those same two dozen tricks from that book, with very minor changes.

Software engineering

That book was originally a paper at a Software Engineering conference. The authors were software engineers. That whole field is about managing and organizing computer programming projects. Just a scattering of things it covers: