A few years ago I was in New York City visiting one of the many world class advertising agencies in town. This particular agency was an award-winning media company handling the online advertising of some of the best-known brands in the world. I’d been invited to meet some people and had hoped to set up an internship for our students. At the time I had recently published a book on OOP and Design Patterns and the lead developer with whom we met, knew of my work.
I was interested in their process. Online advertising campaigns are updated on an ongoing basis, and if it’s not new and fresh, potential customers are likely to click or tap to a different site. They explained how they used a template, and most of what a lot of “developers” did was nothing more than data entry. (Not quite as glamorous as imagined.) As I asked about their process and software development work, the lead developer suddenly said,
We don’t do it correctly.
At the time I had no idea what he was talking about and let it drop. Next, he said, “Most of the time we can’t reuse the same code.” Then it dawned on me. Design patterns are known for reusable code and object oriented programming (OOP) is all about application maintenance and capacity for change. What he was saying was that they hacked through the code to get the job done. Using a template, they could cobble together a workable solution to get the project out the door on time. This is not to say they created junk as far as the end results were concerned. The software worked as expected and looked great—thanks mainly to graphic designers and world-class digital photography. They were right about one thing; hacked code is very hard to re-use.
The Guilt of the Gifted Programmer
At one time or another, just about every decent programmer I know has felt a twinge of guilt either about
- not learning OOP and/or
- not using the OOP he/she knows.
As far as learning OOP is concerned, it’s not that difficult, and if most programmers had started with OOP instead of sequential programming, they would think that OOP programming is the natural way of programming. However, most of us got started writing a little bit of code in a sequence, then we learned procedures (functions) and then procedural programming. Then by learning more coding statements, functions, operations and the like, we got better at it and were able to do more things. Most of the PHP books on programming didn’t do much to help even though some of the authors themselves were OOP programmers.
However, we knew (we all knew!) that there is a different level of programming used by professional programmers; including PHP programmers. After all, ever since PHP 5 we’ve had classes, interfaces and a bunch of other OOP tools built into PHP.
Whether you think you can or you think you can’t, you’re right.
So what’s the hold-up? There seems to be three
excuses reasons for putting off this jump of faith:
- Too busy getting PHP projects finished to take time to learn OOP
- Too difficult and advanced (or no self-confidence)
- Impractical: Ok for academics but not real world development
Let’s address these reasons one at at time:
No Time: The idea that you have to stop the world to learn OOP is wrong. You don’t have to take a hunk of time out of your life, learn OOP, and then go back to programming. You can learn a little at a time and employ it where your can. If you know PHP programming, you can slip in a little OOP here and there. Before you know it, you’ll be writing OOP programs. A good start is with a PHP club like Boston PHP that has a self study group learning advanced PHP and OOP. The group is going through Larry Ullman’s advanced PHP book, a chapter per week. You can go at a faster or slower pace. It doesn’t matter.
OOP is Too Difficult: Most people think that server-side programming like PHP is too difficult to learn. Yet here you are, cranking out PHP programs, creating MySQL databases and doing things no client-side programmer can do. If you take OOP one step at a time, it’s not too difficult. What may be difficult is an OOP way of thinking; almost an OOP Zen state. (I’ll get to that further on.) However, starting and working on practical tasks with OOP is not a genius level activity.
OOP is Impractical Ivory Tower Programming: While colleges and universities teach OOP and design patterns, OOP origins began on both business and academic grounds. Simula 67’s (an early OOP language) primary purpose was to improve the movement of cargo ships through ports. Later, in the 1990s, design patterns developed out of cooperation between companies like IBM and certain academic institutions. OOP and design patterns have always been practical solutions to programming.
The Zen of OOP Programming
The other day I was looking at a simple content management system (CMS) written in PHP. The developer put the whole thing into a single class and let it loose on the PHP community. At first I was appalled, but upon reflection, I figured at least the guy got started using classes. Placing code into a class or interface and using class methods is not OOP programming, but using classes can nudge a developer in the direction of beginning to think in terms of an OOP programmer. In differentiating procedural programming from OOP, Daivd Chelimsky put it most succinctly and accurately:
In procedural programming, a process is expressed in one place in which a series of instructions are coded in order. Whereas in OO, a process is expressed as a succession of messages across objects. One object sends a message to another which does part of the process and then sends a new message off to another object, which handles part of the process, etc. You modify a process by reorganizing the succession of messages rather than changing a procedure. (Single Responsibility Applied To Methods. http://tinyurl.com/9256gey)
By thinking in terms of self-operating modules that communicate with one another, the questions you ask begin to change. You’re not asking about flow of commands (as with a flow chart), but you ask, “Who do I need to talk with to accomplish this task?”
Once you start thinking OOP, you’ll change the way you program, and in the long run, you’ll find it a lot easier to create programs, use modules, and to make changes in very complex systems. You tweak the module, not a spider web of sequences and procedures.
I’d be very interested in any ideas, experiences and tips you have for work with OOP and PHP! Leave a comment, a thought, or an idea.
Copyright © 2013 William Sanders. All Rights Reserved.