Everything up to this point in the course has been procedural — variables, conditionals, loops, and functions, run top to bottom. Object-oriented programming (OOP) organizes code differently: instead of data and the functions that act on it living separately, they're bundled together into a single unit called an object.
In ColdFusion, that unit is a ColdFusion Component (CFC) — a .cfc file that combines properties (data) and methods (functions) into one reusable package. This module covers how to build and use them.
Learning Objectives
After completing this lesson, you'll be able to:
- Explain what an object is and how it differs from the procedural code used so far in this course.
- Name the four pillars of OOP: encapsulation, inheritance, polymorphism, abstraction.
- Give an honest answer to "is OOP worth the overhead here?" instead of treating it as always better.
The Core Idea: Data + Behavior, Bundled Together
Picture a bank account. Procedurally, you'd have a struct holding the balance, and separate functions like deposit(account, amount) and withdraw(account, amount) that take the struct as an argument and modify it.
Object-oriented, the account CFC holds its own balance and its own deposit() and withdraw() methods that operate on it directly — account.deposit(500) instead of deposit(account, 500). The data and the operations that are allowed on it live in the same place.
The Four Pillars
| Pillar | In one line |
|---|---|
| Encapsulation | Bundle data with the methods that operate on it, and hide the internal details |
| Inheritance | A component can build on another component, reusing (and overriding) its behavior |
| Polymorphism | Different components can respond to the same method call in their own way |
| Abstraction | Complex logic hides behind a simple, named method — callers don't need to know how it works |
Each of these gets its own dedicated lesson later in this module — this is just the map.
Is OOP Actually Worth It?
Honestly: not always. For applications that are mostly about storing and displaying data with simple logic, wrapping everything in components adds structure without much real benefit. OOP earns its keep when there's genuine behavior to organize — calculations, workflows, business rules that would otherwise be duplicated across pages.
The realistic middle ground most CFML developers land on: use CFCs for things with real behavior (a service that processes orders, an object that validates and formats its own data), and don't feel obligated to wrap every last database table in a full Bean/Service/Gateway/DAO stack just because OOP is available.
Common Beginner Mistakes
Assuming OOP is always the "more correct" way to write ColdFusion
Plenty of solid, maintainable CFML applications are mostly procedural. OOP is a tool for organizing behavior-heavy code, not a requirement for every project.
Over-fragmenting a simple feature into many tiny components
Creating a separate Gateway, DAO, Bean, Service, and Controller for a single simple table adds indirection without adding real value. Start simpler and split things out only once a component is doing genuinely too much.
Interview Questions
What are the four pillars of OOP?
Encapsulation, inheritance, polymorphism, and abstraction.
What's the practical difference between a procedural function and an object's method?
A procedural function takes the data it operates on as an argument (deposit(account, amount)). An object's method already has access to its own data, so it's called directly on the object (account.deposit(amount)).
Summary
In this lesson, you covered what OOP actually changes about how code is organized, the four pillars, and an honest read on when the extra structure is worth it.
What's Next?
The next lesson covers the difference between a class and an object — and what those general OOP terms map to in ColdFusion specifically (CFCs and instances).