WHAT A TANGLED WEBWE WEAVE

Creating a web page ain’t what it used to be. Setting up a website today usually means
incorporating numerous technologies, among them (X)HTML, CSS, JavaScript, SQL, and a
server-side scripting language. But that’s not all—a web page also runs within a browser. There are several different browsers, of course, and each behaves differently. Not only that, but different versions of the same browser can act differently, and even the same version of the same browser can’t be relied upon to behave the same when running on different operating systems, with different hardware, different screen resolutions, and so on.
Add to this the various configuration files—for the scripting language and the web server, for example—which also affect the display of a particular web page, and you can see that the web developer’s lot is not a happy one.
It may not be readily apparent that an object-oriented (OO) approach is a means of simplifying this situation. OO development might be seen as symptomatic of the larger problem. To the embattled web developer an OO approach can appear to be just another complication of what’s already a messy business.

Do We Really Need Objects?

The ability of any server-side scripting language to “include” files within a web page reduces initial work and ongoing maintenance. For instance, suppose a website contains a menu at the top of each web page, and this menu is iden- tical throughout the site. You could cut and paste the appropriate code into every page, but this is both cumbersome and counterproductive. It’s much better to write the code once and use a server-side scripting language to insert the menu wherever it’s needed. That way, should an update be required, you can make one change to one file rather than changing many files. This makes site-wide updates much easier.
You could summarize this approach as “include and reuse; don’t rewrite.” In a sense, object-oriented programming (OOP) is just an extension of this concept. Objects simplify web development by eliminating the need to cut, paste, and adapt existing code. If the usefulness of OOP were this evident, it would meet with little resistance. This has not been the case, however. Let’s look at some of the more interesting objections to OO web development to remove any nagging doubts you may have.

Just a Scripting Language

PHP is a scripting language. Some of the objections to OOP focus on this fact.
Some scripting languages simply string together a series of commands and for this reason are sometimes referred to as “glue.”1 A shell script, for example, may combine a number of operating system commands in order to eliminate the tedium of repetitively typing the same thing. The variety of requirements of a web page might seem to support the view that PHP is just this sort of scripting language—it provides a glue to hold together the dispa- rate elements of a web page. If this is all that PHP does, then there is probably no need for it to be object-oriented. In fact, object orientation might even be a disadvantage. In this view, which is sometimes expressed with a degree of condescension, OO capabilities are best left to full-blown programming lan- guages and are an unnecessary encumbrance for a scripting language. An OO scripting language is a contradiction in terms; it’s a language that’s “getting above itself.”2
To some extent, the limited OO capabilities of PHP 4 reinforced the view that a scripting language shouldn’t attempt to be object-oriented. PHP 4 looked like a half-hearted attempt to jump on the OO bandwagon. Because it was missing some of the major elements associated with OOP, it was easy to dismiss OO PHP as a wannabe OO language. It simply lacked the tools of a serious OO language. In light of the much-improved OO capabilities of PHP 5, this view needs to be reassessed.

Chapter 3 deals with the improvements to PHP’s object model in version 5. With these improvements, PHP is now a full-blown OO language. It should be judged by how well it does the job, not on the basis of a preconceived notion of what a scripting language should or shouldn’t do. After all, a programming language, scripting or otherwise, is just a tool, a means to an end. Tools are meant to be judged not by what they are, but by what they can do.

Object Orientation Is for Large Software Shops

Another argument against OOP goes like this: OOP is something best left to the large shops. If a number of programmers are involved in the same project, an OO approach is a necessary evil, but it’s not much use for the lone developer. Because big software shops have many different program- mers doing somewhat specialized jobs, the modular, OO approach is required. It is not something that the lone developer needs to worry about. The lone developer doesn’t have to coordinate his efforts with others, so a procedural approach is the better way.
This point of view correctly identifies the fact that an OO approach is more modular and thus more suitable to an environment that requires col- laboration. It is also true that in some circumstances a single developer can do a superior job—too many cooks can spoil the broth. And it is probably also true that taking an OO approach will slow development. But an OO solution takes more time than a procedural one only the first time that the solution is created. The lone developer can benefit from the reusability and adaptability of an OO solution just like any large software shop can.

Leave Well Enough Alone

We’ve dealt with some of the reasoned arguments against an OO approach to web development, but in many cases what’s at work is simply a reluctance to change. PHP has been exceptionally successful as a procedural language. If it ain’t broke, why fix it?
Computer languages, like their natural counterparts, must keep pace with changes in the environment or risk becoming irrelevant. OOP doesn’t replace procedural programming or make it obsolete. Nor is an OO approach always the right approach, as some OO enthusiasts might have you believe. However, some web problems require an OO solution. Additionally, without a minimal understanding of the basics of OOP, you can’t make full use of the capabilities of PHP 5. For instance, if you want to create a SOAP client, there is really no other way to do it than by using the SOAPClient class.
There’s no requirement that once you start programming using an OO approach you need always code this way. PHP is a hybrid language with OO capabilities grafted onto it. You can use an OO approach when you want and otherwise revert to procedural programming.

Increased Complexity

Fear of PHP becoming overly complex is often a more subtly stated objec- tion to an OO PHP. There’s no doubt that OOP can sometimes introduce unwanted complexity—just look at multiple inheritance in C++ or Enterprise Java, for example. This hasn’t happened with PHP, and there’s good reason to suspect that it won’t. PHP is first and foremost a web development lan- guage (which is probably why it has taken so long for PHP to adopt an OO approach). Web programming is a specialized form of programming, and OO capabilities have been introduced to serve this end. The fact that PHP’s implementation of OOP doesn’t always make OO purists happy is indicative of this. Even as a procedural language, PHP was never about being pretty or being a model language; it has always been about solving web problems.
A quick look at the culture of PHP should convince you that PHP is unlikely to develop into an overly complex language.

The PHP Culture

Culture is not something that is usually associated with a programming language, but looking at the culture of PHP will help you understand PHP’s implementation of OOP. PHP is an open-source language created more than
10 years ago by Rasmus Lerdorf. It has all the hallmarks of a successful open- source project: It has been around for a number of years, it is continually being upgraded, it has a robust developer community, and it has continuity of leadership—Rasmus Lerdorf still takes a very active role in its development.
PHP is by far the most popular web development language, and the major reason for its success is ease of use. This is no accident. It is easy to use because it was conceived as a language to simplify web development.3 This has not been forgotten with PHP’s upgrade to a full-blown OO language.
For example, one of the new classes introduced in PHP 5 is the aptly named SimpleXMLElement. With this class you can incorporate an RSS feed into a web page using only four lines of code (see Chapter 12).
The point of object orientation in PHP is not to turn PHP into Java or something similar, but to provide the proper tools for web developers. Object orientation is another strategy for adapting to the current circumstances of web development.

NOTE The impetus to “Keep It Simple, Stupid” is alive and well (and, as it happens, living in Paris). At a recent meeting of PHP core developers, the introduction of a new keyword was rejected as “against the KISS approach of PHP” (minutes, PHP Developers Meet- ing, Paris, November 11 and 12, 2005).

Unquestionably, there will be a learning curve for a procedural program- mer adopting an OO approach to web development, but you’ll quickly pick up on PHP’s implementation of OOP. In fact, you’ll probably find that some of the tasks you’re used to doing procedurally are more easily done in an OO manner. I suspect that once you’ve started on the OO path, you’ll find more and more uses for it.