Object-Oriented Programming (OOP)
Get a conceptual overview of what object-oriented programming is, why it matters, and the four pillars you will explore in the coming lessons.
Introduction
So far, every lesson in this course has used a procedural style — variables, functions, and control structures operating on data that is passed around explicitly. This works well for smaller scripts, but as applications grow, it can become difficult to keep track of which functions are allowed to touch which data.
Object-Oriented Programming (OOP) is a different way of organizing code: instead of separating data and the functions that operate on it, you bundle them together into self-contained units called objects. This lesson is a conceptual overview — you will not write much class syntax yet. The goal is to understand what OOP is and why it exists before diving into the mechanics in the next lesson.
- What object-oriented programming means, conceptually.
- Why OOP helps as applications grow larger and more complex.
- How procedural and object-oriented styles compare, side by side.
- A preview of the four pillars of OOP: encapsulation, inheritance, polymorphism, and abstraction.
What Is OOP?
Object-oriented programming is a way of modeling your code around "objects" — self-contained units that bundle together data (called properties) and the behavior that acts on that data (called methods). Instead of a Car being represented as several loose variables and functions scattered around your script, a Car becomes a single object that knows its own speed, color, and how to accelerate.
Bundles Data + Behavior
An object keeps its properties and the methods that operate on them together, in one place.
Models Real-World Things
Objects like User, Product, or Invoice map naturally onto the concepts your application deals with.
Encourages Reuse
A class acts as a blueprint, so you can create many similar objects without duplicating logic.
Controls Access
Objects can hide their internal details and expose only what other code actually needs to use.
Why OOP Matters
In a small script, procedural code is perfectly fine — a handful of functions operating on a few variables is easy to follow. But as an application grows to dozens or hundreds of files, keeping track of which functions modify which data, and in what order, becomes increasingly difficult.
OOP addresses this by grouping related data and behavior into objects. If you are working with a "User", all the logic for validating a user, checking their permissions, or updating their profile can live inside a single User class, rather than being spread across many unrelated functions that all take a $user array as an argument.
Think of a class as a blueprint and an object as something built from that blueprint. A "Car" class describes what every car has (speed, color, fuel level) and can do (accelerate, brake); each individual car you create from it is a separate object with its own values for those properties.
Procedural vs Object-Oriented Style
To see the difference concretely, here is the same small idea — a bank account with a balance that can be deposited into — written both ways.
<?php
// Procedural style: data and behavior are separate
$account = ["balance" => 100];
function deposit(array &$account, float $amount): void {
$account["balance"] += $amount;
}
deposit($account, 50);
echo $account["balance"];150<?php
// Object-oriented style: data and behavior live together
class Account {
public float $balance = 100;
public function deposit(float $amount): void {
$this->balance += $amount;
}
}
$account = new Account();
$account->deposit(50);
echo $account->balance;150Both produce the same result, but notice how the object-oriented version keeps balance and deposit() bundled together inside Account, instead of relying on a loose array and a separate function that has to be passed that array every time.
The Four Pillars of OOP
Object-oriented programming is usually described in terms of four core ideas, often called the "four pillars." Each one gets its own dedicated lesson soon, but here is a quick preview of what each means.
Encapsulation
Bundling data and the methods that work on it together, while controlling access to that data using access modifiers (like public and private). Covered in the Access Modifiers lesson.
Inheritance
Allowing one class to inherit properties and methods from another, so related classes can share common behavior instead of duplicating it. Covered in the Inheritance lesson.
Polymorphism
Letting different classes respond to the same method call in their own way, so code can work with objects generically. Covered in the Polymorphism lesson.
Abstraction
Hiding complex implementation details behind a simple interface, so you only need to know what an object does, not how. Covered in the Abstract Classes lesson.
You do not need to fully understand all four pillars right now. This lesson is just a map of what is coming — the next several lessons will introduce classes and objects, then build up to each pillar with dedicated examples.
What's Coming Next
The very next lesson dives into the actual syntax for defining classes, creating objects, and working with properties and methods. From there, the course builds up through constructors, access modifiers, inheritance, polymorphism, and abstraction, giving each pillar the space it deserves.
- Classes & Objects — how to define a class and create objects from it.
- Constructors & Destructors — running setup and cleanup code automatically.
- Access Modifiers — encapsulation in practice with public, protected, and private.
- Inheritance — sharing behavior between related classes.
- Polymorphism — letting different objects respond to the same call differently.
- Abstract Classes — designing flexible, high-level blueprints.
Common Mistakes
- Assuming OOP is always "better" than procedural code — for small scripts, procedural style is often simpler and perfectly appropriate.
- Trying to memorize the four pillars in the abstract before seeing real code — the concepts click faster once you have written a few classes.
- Confusing a class (the blueprint) with an object (something built from that blueprint).
- Thinking OOP is a completely separate language feature rather than a different way of organizing the same PHP you already know.
Best Practices
- Think of classes as blueprints and objects as the concrete things built from them.
- Reach for OOP as your codebase grows and data plus its related behavior start feeling tangled together.
- Do not force OOP onto tiny scripts where a couple of functions would be simpler and clearer.
- Revisit this lesson after finishing the OOP section — the four pillars will make far more sense in hindsight.
Frequently Asked Questions
Do I have to use OOP in PHP?
No. PHP fully supports procedural programming, and plenty of scripts and even some frameworks favor it. However, most modern frameworks (like Laravel and Symfony) are built heavily around OOP, so understanding it is valuable.
What is the difference between a class and an object?
A class is a blueprint describing what properties and methods something will have. An object is a concrete instance created from that blueprint, with its own actual values.
Are the four pillars unique to PHP?
No, they are general object-oriented programming concepts shared across languages like Java, C++, Python, and many others. Learning them here transfers directly to other languages.
Is OOP always faster or better than procedural code?
Not necessarily faster, and "better" depends on context. OOP mainly offers better organization and maintainability for larger, more complex applications.
Do I need to understand all four pillars before writing my first class?
No. The next lesson introduces basic class and object syntax, and the pillars are layered in one at a time afterward.
Key Takeaways
- OOP bundles data (properties) and behavior (methods) together into objects.
- It helps keep larger applications organized as the number of files and features grows.
- A class is a blueprint; an object is a specific instance created from that blueprint.
- The four pillars of OOP are encapsulation, inheritance, polymorphism, and abstraction, each covered in upcoming lessons.
- Procedural and object-oriented styles can solve the same problem differently — OOP is a tool, not a requirement.
Summary
Object-oriented programming reorganizes code around objects that bundle data and behavior together, making larger applications easier to reason about and extend. The four pillars — encapsulation, inheritance, polymorphism, and abstraction — describe the core ideas that make this style powerful, and each will get its own dedicated lesson soon.
Next, you will roll up your sleeves and learn the actual syntax for defining classes and creating objects in PHP.
- You understand what OOP means and why it exists.
- You can compare procedural and object-oriented approaches to the same problem.
- You know the four pillars of OOP by name and what each one previews.
- You are ready to write your first real PHP classes.