Basic Object-Oriented Programming in PHP
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.