All compromise is based on give and take, but there can be no give and take on fundamentals. Any compromise on mere fundamentals is a surrender. For it is all give and no take.
People talk fundamentals and superlatives and then make some changes of detail.
An unfortunate thing about this world is that the good habits are much easier to give up than the bad ones.
For years after I started programming regularly, I developed certain habits that changed from sequential to procedural programming and just cruised along on a combination of those two for years. This was due in part to the explorations of different languages. My first was Fortran II in college, then on to Basic, FORTH, PostScript, and then into assembly and machine language. I was more interested in learning about different languages than I was in good programming. Then with the Internet came Java, JavaScript, PHP, C#, and ActionScript 3.0, among others. Most of these languages were based (in part) on the kinds of structures found in C++. These were different languages, but I maintained the same old habits.
Quite by accident, I was introduced to state machines by Dr. Jonathan Kaye. Instead of thinking in terms of flow of control, he showed me how to think in terms of different states. Following state machines, I discovered the State design pattern and then Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (Addison-Wesley). The examples in Design Patterns were all written in SmallTalk or C++. Knowing no SmallTalk and very little C++, I was forced to concentrate on the conceptual materials. Oddly, that was one of the best things that could have happened because I was not stuck with examples in any particular language. When it came to PHP, it wasn’t a matter of translating from SmallTalk to PHP but applying object-oriented programming (OOP) and design pattern concepts directly to PHP.
Slowly but surely, my programming habits began to change. By adding a little OOP here and there and incorporating a design pattern now and again, in time, I didn’t want to program any other way. According to psychologists, a habit is formed over a period of 66 days on average, but in my case, the change took longer and it was more gradual. It was a very busy development period for me, and when the choice was between getting a project done for a customer and using OOP and design patterns, time pressures always won out. However, more and more OOP was creeping in my habitual coding practices, and before I knew it, my customers were getting solid OOP and design pattern-developed applications. The four chapters in this first section are designed to get you started on the OOP path:
PHP and Object-Oriented Programming
Basic Concepts in OOP
Basic Design Pattern Concepts
Using UMLs with Design Patterns
Most of the good programmers I know have a certain style that points to professional programming habits. By and large, when you encounter good OOP programming, you’ll see a certain way of doing everything from naming variables to commenting code. Variable names are clear, and comments in the code tell the story of the code so that other programmers know how to connect to their own modules. In this book, the comments in the code have been kept to a minimum because that job is done by the book’s text. Further, I have often found that putting in too many comments get in the way of clearly seeing the structure of the code. So, with the goal of being able to see and sense objects as complete entities, the code is not fractionalized by long-winded comments. (In programs not written for books, I subscribe to the idea that substantive commenting is essential.)
For some reason, PHP seems to be plagued by bad examples of design patterns. By bad, I’m not talking about dumb examples. I’m referring to design patterns written with missing parts. For example, a Strategy pattern written without a Context participant is a bad example. It is simply inaccurate. The same is true for any pattern that has missing parts. It’s like writing a loop that has no termination condition. The Strategy pattern requires a Context just like a loop structure requires a termination condition.
In order to keep the focus as accurate as possible, I’ve used the original source of the design patterns discussed in this book: Design Patterns: Elements of Reusable Object-Oriented Software (Prentice Hall). Further, the Uniform Modeling Language (UML) is the one used in Design Patterns. Newer versions of the UML (UML2) have come along since then, but for learning PHP design patterns, and for understanding ones not discussed in this book, learning to use the original will help if you want to learn additional patterns from the original source.