Object-Oriented, Like It or Not

In a former life I was a teacher of Art and English. It was a valuable experience that taught me a lot about the organization of thoughts and ideas. Every teacher has a different approach. Some teachers begin by entering their class and talking about what they know, while others first spend time preparing a syllabus, with outlines, main topics, and clear starting and stopping points. Either method can be effective under certain conditions. If you were to attend a seminar that lasted 3-4 hours, it’s very possible that you would benefit equally from either teaching method. If, however, you were to attend a college course that had 30 sessions lasting 2-3 hours each, which teacher would you prefer to have? The teacher with syllabus and clearly defined topics is likely going to be much easier to follow. Additionally, since that teacher has broken down their discipline into logical building blocks, you are likely to come away from that course with a very structured understanding of the subject matter, which will give you the ability to go much further, and much faster.

The shoot-from-the-hip teacher would probably run out of things to say before the end of the first week. Nevertheless, there are some who may have chosen this teacher, and I don’t blame you. After all, who doesn’t love free time, am I right? Seriously, sometimes a teacher who can just sit down and talk about a subject matter like they’re just having a cup of coffee with you, can be much easier to learn from. I have had at least one teacher who taught casually and seemingly unprepared, but nevertheless effectively; that teacher was the best I’ve had, ever. Nevertheless, not only are the good ones an exception, they are also an illusion; just because a teacher seems like they haven’t prepared a structured approach, doesn’t mean they haven’t. I argue that any teacher who trains their students effectively, and equips them with the subject matter thoroughly, does so partly, even largely, through the process of organization and structure. Sometimes the best organization and structure will sneak up on you like it was never there.

So anyway, long-winded speech to make a simple point. Coding is a lot like teaching, you’re just not teaching a human. You are, however, teaching a computer, which knows far less than a human, and assumes far less as a consequence, which is both good and bad. You are also leaving a trail of information for other human teachers (coders) to pick up on later, and therein lies one of the primary reasons to make sure that you’re code is organized.

In the years that I’ve spent learning PHP, one of the major challenges I faced was deciding whether I wanted to continue learning PHP. I’ve heard a lot of criticism of the language in the professional developers circles, one of the primary criticisms being that it’s not an object-oriented language. To many PHP developers, this comment is like fingernails on a chalkboard. The PHP development community is predominantly made up of procedural developers who could care less that PHP may or may not be strictly OO, and they’ve made a lot of decent arguments for procedural development. Understanding the two sides of this debate can be tricky because, as would be expected, procedural developers are obviously going to argue for procedural development, and object-oriented developers are usually going to argue for OO development. However, among the arguments that I’ve heard that I consider to be the most objective, from either side, the verdict tends to be, that whichever method you choose should depend predominantly upon the project, and as a general rule, when dealing with larger development projects, the more that your methods are object-oriented, the better off you’re going to be.

When I first began understanding the concepts of OO methodology, I was just stepping into PHP5. I felt that PHP5 was pretty object-oriented, and I didn’t really understand what some PHP critics were talking about when they said it wasn’t (yes, many were talking about PHP4, but some were, even then, directing their comments toward PHP5). Since that time I’ve worked quite a bit with javascript, and having now made a decent comparison of the two languages, I have a much better understanding of what an OO language is all about, and PHP5 is not extremely object-oriented when compared to languages like javascript or ruby. Nevertheless, I still believe you can build a strong OO application based on PHP if you know what you’re doing.

One of the primary end results of object-oriented development, in my opinion, is simply organization. It just makes more sense, for example, to take all the code that pertains to the user and place it in a user object, rather than intermingle it with a bunch of other code.

There are many procedural developers who don’t use classes to organize their code into objects, but do use files to accomplish some similar organization. For example, they may have a file called user.php where they place all of the code pertaining to the user. This is a very positive step in the right direction. However, the level of organization when using classes is still far better. Files give you the advantage of code separation, but they are still missing the advantage of trails. For instance, if I have a class called user, and somewhere in my code I have to refer to a user, I do so by creating a user object, like so:

$user = new User;

Then, if I need to refer to the user’s name, I do that like so:

$user->name = "Johnny";

If I want to refer to a group that a user is in, I could do that like this:

if ($user->groups->member) echo "Welcome back, valued customer.";

And again, if I wanted to refer to the permissions of a group that the user is in, I might do that like this:

if ($user->groups->member->allowPublish()) {
    echo "Publish documents.";
} else {
    echo "Sorry, but you are not allowed to publish documents.";

This makes your code very easy to follow. Looking at the previous permissions check and reading from left to right, it’s fairly straight forward to understand what we’re doing, i.e. we’re checking to see if the user is in a group called member that is allowed to publish. Even better, looking at the last member of that call, allowPublish, we can tell it’s a function because it’s followed by a set of parentheses, and now we have a good idea of where the function is located, i.e. it is a method of a class that handles groups, very likely a class called “member”; assuming that we’re using sensible variables, we’re now on a fast track to fast tracking. If this were procedural programming, this function would most likely be sitting on a line by itself without any trail or clues for tracing, so the fact that it’s a function would be all that we would be able to deduce.

OO methodology is also designed to make your code much more reusable, because when executed properly it separates code according to its purpose. For example, perhaps you are creating a social news site which will allow your visitors to create accounts and publish news. For this project you will need to design various bits of functionality, such as:

  • The code that allows users to register, sign in, and write news articles
  • The code that sorts the news articles by category and publication dates
  • The code that formats all this information for viewing on web pages

Now imagine that months after this project is completed and live, you are given the task of designing a photo gallery. This new project has very little in common with your prior project, namely user accounts, and perhaps some of the code that formats information for web pages. Trying to reuse your prior project to suit the needs of the current project is out of the question. If you want to reuse the user code and formatting code, you’ll have to pull it out of your prior project and begin building upon it afresh. If you built the prior project procedurally, it is likely that sifting out the pertanent code snippets is going to be confusing, because chances are you have intermingled user code with input code with publishing code with database code with formatting code. On the other hand, if you built your site using OO methodology, you’re almost certainly in much better shape. Applying OO methods to your prior project, you will have built a class for each bit of functionality, i.e. a user class for everything the user needs to do, a formatting class for all of the formatting that needs to be done, perhaps a news class for creating and accessing news, etc. To reuse the user and formatting functionality in your new project, all you need to do is cut and paste the user and formatting classes over to your new project. You might also need to sift out the few areas in the classes that access other classes; but if you’ve done a really good job with these classes, chances are there are little, if any, areas that do that. Reusable OO code done well means clip, paste, and go. Reusable code reduces your long-term workload, which will either increase your profit margin or make you much more competitive.

OO methodology is also famous for abstraction, because it makes it very easy to design generic objects with generic properties that can take on many specific forms during runtime. Anytime you define a variable in a class and outside of the functions in that class, that variable is understood by PHP as a property of that class. Also, any functions that you define in that class are understood by PHP as methods, or actions that the class can perform. These methods can perform their actions differently based upon how the properties of the class/object are defined. When a class is instantiated as an object during runtime, you can define a method for the class to define its own properties during instantiation, or you can define the properties of the object after instantiation from outside the object under certain conditions.

I can speak from personal experience when I say that OO methods have made my job much easier and quicker. In a future article, I’m going to take some time to explain my own approach to OO development in PHP.


No comments for “Object-Oriented, Like It or Not”

Post a comment