"If you think of coding as the manipulation of data, you’re going to have a hard time writing object-oriented code."

That’s an off-the-cuff comment I made during a presentation at the Nashville PHP meetup last night, and one of the attendees messaged me later asking if I could expand on that thought.

First, I think a definition is important. Data is facts, statistics, quantities, values, characters, etc. In the context of programming, it’s anything that can be assigned to a variable.

Procedural code sends data through a series of instructional steps to accomplish the goals of the business. Functions may be used to make it more modular, but if the emphasis is on manipulating data as it flows through a series of steps, it’s procedural code.

Object-oriented programming is all about accomplishing the goals of the business through a community of collaborating objects, the design for which must start with a deep understanding of the business itself. Data isn’t irrelevant in OOP, but an object isn’t just a dumb bag of data either. It’s an agent of purpose for the business. Data is important only insofar as the object needs to know certain things to accomplish its role. (Notably, in many cases the specific data an object holds in order to accomplish its purpose could change without the purpose itself changing.)

Data is in service to the purpose. It isn’t the purpose itself. Ultimately, all data in software is surrounded by a boundary that defines purpose and gives meaning to the data contained within. With procedural code, it’s often the user interface layer doing that work for the entire system. In OOP, it’s each individual object.

So it’s a big difference in mindset. In my opinion, if you start by thinking about the data and how it’ll be stored, structured, and manipulated, you’re already concerned with tactics before you even have a strategy. You’re starting from the wrong end of things, and it will dramatically affect how you design the entire system.