Hi, folks. Welcome back. In 1995, a group of four software developers published this book. Design Patterns. At the time, the authors were informally known as the gang of four. The book was a hit in its time, but I want to talk about it in this lecture. Because it marked a turning point. Also the principles behind the book, if not the exact contents are more important today than when the book was written 95. Patterns in software development had long been recognized. Many lessons back, we talked about the origins of the waterfall process and how it is extend from people noticing the many software projects with similar things. There was always a requirements phase of some sort or time spent figuring out what to do. A rough sketch of what was to do was developed in a design phase and so forth. In the 1970s, imperative programming languages, such as COBOL, ALGOL, Fortran and C were used. Computer programs were simply a list of commands for the computer to perform. Reading some information. Add something up. Print out or store information. These programs were elaborate, but the languages in which they were written implied no structure. In the 1980s, the Pascal language introduced the notion of structured programming. Much to the horror of season imperative language programmers, there is no go-to statement. Loops had constraints and of statements had blocks of code to be executed under certain conditions. There is no arbitrary change in the program flow. Structure was further enforced with the rise of object-oriented languages in the 1980s. The object-oriented version of C was C++. In C++, you could define a class and then create objects as instances of that class. This class definition was the pattern and the instantiated object were like cookies stamped out of a sheet of dough. They all resembled each other at a certain level, but they could be decorated differently. Patterns had entered coding. At the same time, relational databases came about lending patterns to the structure of databases. So it was fitting that a little while later in the 1990s, patterns moved forward from the implementation phase to the design phase of software projects. 1979, Christopher Alexander, a British architect published a book about architectural patterns. The Timeless Way of Building. The book presented how houses, gardens, blocks, neighborhoods, quarters, towns and cities could all be designed from similar patterns. The software world picked up on this. And now, Mr. Alexander's name is bandied about among the cognoscenti in the pattern programming world. So it's fitting that in the mid-90s, design people started talking patterns. The introduction of design patterns. Definition of a design pattern taken from Alexander. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem in such a way that you can use the solution a million times over without ever doing it the same way twice. The design patterns book then discusses as an example for model view controller pattern we talked about in the previous lesson. As an example, the authors of design patterns show how you can design a Wizzywig or what you see is what you get document editor from patterns and then a thorough description of 23 different patterns they thought important at the time as presented. Now while a lot of the patterns have been superseded by others rendering the specifics of the books somewhat antiquated, the notion that designs for complex projects are repetitions of existing common design patterns is still valid. I talked about using the voice over IP on a project in a previous lesson. Voice over IP didn't exist in the mid-90s, so there's no pattern for it. However, in my project, I discovered a pattern that worked well for me and now I can continue to employ that pattern in the future on similar projects. And in the discussion of high-level design, I talked about finding the fault lines and assessing the risk or areas bounded by fault lines. Voice over IP was mentioned as a high risk area for me. And so, I spend time prototyping and figuring out how I could best implement voice over IP. The problem was I didn't have a pattern for voice over IP. I had never done that before. So even when you're embarked on something new, patterns are still important. Identify them as part of your solution. Evaluate them. Minimize risk by prototyping them. And as you gain experience in design, you'll have more and more patterns in your toolbox which will make new projects much more fun to build. Thanks.
