I do a bit of web development on the side, and decided to learn me some object-oriented PHP. I recently took on an ecommerce project, and thought I’d walk you, the reader, through the process so we can learn object-oriented PHP together. I’m making few assumptions about your experience with object orientation, but I will assume you know a bit of PHP. If something is unclear, I’ll be happy to address it in the comments.

That said, we should probably start with a discussion of the concept of object orientation.

What is object orientation, anyway?

There are two big schools of thought when it comes to programming. Procedural orientation, and object orientation. They’re both methods by which programmers attempt to minimize how much code needs to be written, and each have their strengths and weaknesses.

Procedural orientation has been the dominant programming paradigm since the earliest days of computers. Essentially, it’s a way of approaching programming as a set of procedures. You could perhaps think of these procedures as automated flowcharts. Flowcharts are a way of breaking a task down into a series of simple, discreet actions and decisions. By building a function (or procedure), you’re essentially writing a flowchart for the computer to follow. By writing a function to handle a repetitive task, you can avoid duplicating your own efforts, and allow the computer to play the role of mindless drone, instead of yourself. Procedural orientation is basically “do this, then do this, then do this”.

Object orientation, while it’s been around in one form or another since the 1960s, has really only gained popularity in the last 15 or so years. OO, as it’s commonly called, is better described as a set of objects that accomplish a task by interacting with each other. Everyone has a pet metaphor to describe OO, and mine is an office. When working in an office, you’ve got a whole range of tools, or objects, at your disposal. You may have, say, a fax machine, a secretary, a cell phone, a FedEx guy, etc. (you’ll notice I have little problem objectifying people for the purpose of the discussion). Each of these objects (or people, whatever, get over it) knows certain things and can do certain things. If I need a package picked up, I’ll pick up my cell phone object, and use it to call the FedEx guy. Note that I don’t actually need to know his phone number, only that the cell phone knows it. Once I’ve got the FedEx guy on the line, I’ll give him the dimensions, weight, destination, etc. of the package, and let him handle the rest. I don’t need to tell him how to gas up his truck, put it in gear and drive over; that’s his job.

So, if you were to write a program that imitates an office, you’d need a cell phone object, FedEx guy object, fax machine object, and so forth. Each of the objects would have a set of properties (things it knows, or variables) and methods (things it can do, or functions). Each of these objects will need to be given it’s properties (e.g., someone has to program contacts into a cell phone), and taught how to perform it’s methods (e.g., someone has to show the FedEx guy how to gas up the truck). The nice thing is that once an object is defined (the definition itself is called a class; more about that later), you, or another programmer, can go in and program the methods without worrying too much about what’s going on in the rest of the program (e.g., the office). The gas station attendant can show the FedEx guy how to gas up, Cingular can teach my cell phone how to place a call, etc. Object orientation is basically “you do this, and you over there do that, and this other guy will handle this other thing“.

So what are the benefits of OO?

• Modularity – Well-written OO code is very modular. You can almost think of individual objects as Lego blocks that can be snapped together to build whatever your heart desires. Of course, you need to design the individual objects, but once they are defined, you can create and use as many as you need to build your project.
• Code Reusability – Inheritance allows you to define superclasses. Let’s revert to our office metaphor, and say you have three devices: a plain, boring cell phone, a camera phone, and a Blackberry. They are all different, but they share certain functionality. In this case, you would define a superclass that contains the properties and methods all three devices have in common. Let’s call our hypothetical superclass “WirelessDevice”. All three of our devices have a phone number associated with them, so our WirelessDevice superclass will include a property to store a phone number. All three of our devices allow us to place and receive calls, so the WirelessDevice superclass will include appropriate methods. Not all of our devices have a camera, so the superclass won’t include a method devoted to taking pictures. Now when we define our classes for the cell phone, camera phone, and Blackberry, we can just indicate that the classes inherit from the WirelessDevice superclass. In doing so, our new classes automatically include the properties and methods from the superclass, thereby saving us from having to re-write the code for every new class.
• Maintainability – With procedural code, you often have to step through lengthy, complex functions to figure out how the code works in order to debug or improve it. OO code is generally much easier to dig into and modify. Creating objects and calling methods associated with objects is usually more comprehensible.
• Organization – OO code is by nature an extremely organized way of approaching programming. If a project is well-written, it is almost by definition well-organized.

And the drawbacks?

• Unnecessary complexity – Unfortunately, due to the structure of object orientation, it is frequently simpler and more straightforward to accomplish a task using a procedural approach. The smaller the project is, the more true this usually is.
• Bloat – Again, due to it’s structure, OO projects can be quite a bit lengthier than procedural projects.
• Speed – Longer code almost always means slower code.

PHP and object orientation

PHP did not start out as an object-oriented language. Really, it’s just a scripting language, and it wasn’t though that such fancy functionality belonged in a lowly scripting language. With version 3 of PHP, some OO functionality was built in, but it was a half-hearted attempt at best. It was a really stripped-down version of object orientation, and didn’t include many of the most useful features we’ve come to expect from OO. Unfortunatly, version 4 saw little improvement on the OO front, and not until the current version, version 5, has PHP evolved into a full-blown object oriented language.

Where to from here?

So why try to learn to build sites using object oriented PHP? Because we can. Because we’re curious and want to learn. Because there are some intriguing concepts that could prove useful for future projects. I don’t claim OO PHP is any better than procedural PHP, but I would like to figure out first-hand the strengths of each. Fortunately, PHP doesn’t make us choose. We can mix it up however we’d like. Once we’ve got a better handle on the OO side of things, we’ll be able to make more informed choices on future projects.

We haven’t had a chance to really dig into code yet, but fear not! We’ll do just that in the next installment of this series. We’ll get our hands dirty, make a mess, screw things up, fix them, break them again, and learn a ton in the process.

Popularity: 13% [?]

Hey, Digg or Stumble My Post. You know you wanna!

Hide Sites

If you enjoyed this post, make sure you subscribe to my RSS feed!