PHP Advanced and Object-Oriented Programming (2013)

---

Although PHP is still not as strong in its OOP feature set as other languages, object-oriented programming in PHP has a lot going for it. And while it is possible to have a good career without learning and using OOP, you should familiarize yourself with the concept. At the very least, being able to use both OOP and procedural programming allows you to better choose the right approach for each individual project.

In this chapter, and the next (Chapter 5, “Advanced OOP”), I will explain not only the syntax of OOP in PHP 5 and later, but the key underlying OOP theories as well. In this chapter, I will use somewhat mundane examples, but in subsequent chapters, practical, real-world code will be used. Through multiple examples and plenty of explanation, I hope in this book to fully demonstrate not just how you do object-oriented programming in PHP but also when and why.

OOP Theory

The first thing that you must understand about OOP is that it presents not just new syntax but a new way of thinking about a problem. By far the most common mistake beginning OOP programmers make is to inappropriately apply OOP theory. PHP will tell you when you make a syntactical mistake, but you’ll need to learn how to avoid theoretical mistakes as well. To explain...

All programming comes down to taking actions with data: a user enters data in an HTML form; the PHP code validates it, emails it, and stores it in a database; and so forth. These are simply verbs (actions) and nouns (data). With procedural programming, the focus is on the verbs: do this, then this, then this. In OOP, the focus is on the nouns: with what types of things will the application work? In both approaches, you need to identify both the nouns and the verbs required; the difference is in the focus of the application’s design.

The two most important terms for OOP are class and object. A class is a generalized definition of a thing. Think of classes as blueprints. An object is a specific implementation of that thing. Think of objects as the house built using the blueprint as a guide. To program using OOP, you design your classes and then implement them as objects in your programs when needed.

One of the tenets of OOP is modularity: breaking applications into specific subparts. Web sites do many, many things: interact with databases, handle forms, send emails, generate HTML, etc. Each of these things can be a module, which is to say a class. By separating unrelated (albeit interacting) elements, you can develop code independently, make maintenance and updates less messy, and simplify debugging.

Related to modularity is abstraction: classes should be defined broadly. This is a common and understandable beginner’s mistake. As an example, instead of designing a class for interacting with a MySQL database, you should make one that interacts with a nonspecific database. From there, using inheritance and overriding, you would define a more particular class for MySQL. This class would look and act like the general database class, but some of its functionality would be customized.

Another principle of OOP is encapsulation: separating out and hiding how something is accomplished. A properly designed class can do everything you need it to do without your ever knowing how it’s being done. Coupled with encapsulation is access control or visibility, which dictates how available components of the class are.

Those are the main concepts behind OOP. You’ll see how they play out in the many OOP examples in this book. But before getting into the code, I’ll talk about OOP’s dark side.

First of all, know that OOP is not a better way to program, just a different way. In some cases, it may be better and in some cases worse.

As for the technical negatives of OOP, use of objects can be less efficient than a procedural approach. The performance difference between using an object or not may be imperceptible in some cases, but you should be aware of this potential side effect.

A second issue that arises is what I have already pointed out: misuse and overuse of objects. Whereas bad procedural programming can be a hurdle to later fix, bad OOP can be a nightmare. However, the information taught over the next several chapters should prevent that from being the case for you.

Defining a Class

OOP programming begins with classes, a class being an abstract definition of a thing: what information must be stored and what functionality must be possible with that information? A User class would be able to store information such as the user’s name, ID, email address, and so forth. The functionality of a User could be login, logout, change password, and more.

Syntactically, a class definition begins with the word class, followed by the name of the class. The class name cannot be a reserved word and is often written in uppercase, as a convention. After the class name, the class definition is placed within curly braces:

class ClassName {
}

Classes contain variables and functions, which are referred to as attributes (or properties) and methods, respectively (you’ll see other terms, too). Collectively, a class’s attributes and methods are called its members.

Functions are easy to add to classes:

class ClassName {
function functionName() {
// Function code.
}
}

The methods you define within a class are defined just like functions outside of a class. They can take arguments, have default values, return values, and so on.

Attributes within classes are a little different than variables outside of classes. First, all attributes must be prefixed with a keyword indicating the variable’s visibility. The options are public, private, and protected. Unfortunately, these values won’t mean anything to you until you understandinheritance (in Chapter 5), so until then, just use public:

class ClassName {
public $var1, $var2;
function functionName() {
// Function code.
}
}

As shown here, a class’s attributes are listed before any method definitions.

The second distinction between attributes and normal variables is that if an attribute is initialized with a set value, that value must be a literal value and not the result of an expression:

class GoodClass {
public $var1 = 123;
public $var2 = 'string';
public $var3 = array(1, 2, 3);
}
class BadClass {
// These won't work!
public $today = get_date();
public $square = $num * $num;
}

Note that you don’t have to initialize the attributes with a value. And, aside from declaring variables, all of a class’s other code goes within its methods. You cannot execute statements outside of a class method:

class BadClass {
public $num = 2;
public $square;
$square = $num * $num; // No!
}

With all of this in mind, let’s create an easy, almost useless class just to make sure it’s all working fine and dandy. Naturally, I’ll use a Hello, world! example (it’s either that or foo and bar). To make it a little more interesting, this class will be able to say Hello, world! in different languages.

To define a class

1. Create a new PHP document in your text editor or IDE, to be named HelloWorld.php (Script 4.1):

<?php # Script 4.1 - HelloWorld.php

2. Begin defining the class:

class HelloWorld {

Using the syntax outlined earlier, start with the keyword class, followed by the name of the class, followed by the opening curly brace (which could go on the next line, if you prefer).

For the class name, I use the “uppercase camel” capitalization: initial letters are capitalized, as are the first letters of new words. This is a pseudo-standardized convention in many OOP languages.

Script 4.1. This simple class will allow you to say Hello, world! through the magic of objects! (Okay, so it’s completely unnecessary, but it’s a fine introductory demonstration.)