Disclaimer: I borrowed the title of this post from Maggie Nelson. While she has retired it as the name of her blog, I feel it's fitting for this post given the nature of its content.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. College gave me the core concepts of the paradigm, but the exact definition for it seems to vary between academic and enterprise institutions and even among individual organizations within either environment. So what does the term mean anymore? How do you know if a language is or isn't object-oriented?

PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects). Would-be operators and constructs are messages and there are no primitive types that exist outside the object system. Preventing the existence of logic outside of classes by having a static method to designate the entry point doesn't cut it. That's the purist perspective, and surprisingly few languages actually meet this requirement.

Simula was the first language to support so-called objects, but even it had language constructs. The first language to which the phrase "object-oriented programming language" was applied (and really the only one I've seen that it does apply to from a purist perspective) is Smalltalk. Ruby supports procedural and functional programming, so in that sense it's not a purely object-oriented language either. The same argument applies to Python. Groovy too. (println anyone?)

But does all that really matter? Should a language not be considered object-oriented simply because object orientation is a subset of its feature set and it offers access to other paradigms? There are four main fundamental concepts of object-oriented programming.

• Abstraction: The ability to organize logic based on higher and lower levels of detail and thus deal with issues at the appropriate level.
• Inheritance: The ability to form new classes of logic by reusing and refining logic from other classes that have already been defined such that the DRY Principle is maintained.
• Encapsulation: The ability to have units of logic within classes act as black boxes, hiding details and allowing other classes to call those logical units without being aware of how they work.
• Polymorphism: The ability to treat an instance of a subclass as one would treat an instance of its base or parent class.

In some way or another, all the aforementioned languages support each of these concepts. It may be more accurate to describe individual bodies of code as being object-oriented or not, based on whether they exist strictly (or as closely to it as the language in question will allow) within the object-oriented programming constructs of that language.

As an example, Zend Framework does require a bootstrap file that doesn't necessarily have to exist within a class (though it could, but would likely be for its own sake). That aside, all its components exist as classes. Its overall design is intended to support code built on top of it existing within classes as well. To a degree, this has been influenced by the object model changes that came out with PHP 5.

So, purist or non-purist, regardless of what you do or don't consider to be OOP, I don't see the spread of OOP as a term diminishing anytime soon. If you're a purist and chastise others when they use the term OOP in a way that you consider to be inaccurate, chances are you're most likely just spinning your wheels anyway.