You DON'T KNOW what Object-Oriented Programming is

Object-Oriented Programming (OOP) is a widely debated topic, with many misconceptions surrounding its true definition and principles. This article aims to clarify what OOP truly entails by exploring its historical roots, its creator's vision, and common misunderstandings, particularly concerning Java programming language. The creator of OOP, Alan Kay, defined it as more than just classes and inheritance; he emphasized message passing, local retention, protection, encapsulation of state/process, and late binding. Many developers confuse OOP with specific implementations found in languages like Java, focusing on concepts such as classes, inheritance, and polymorphism, which are not fundamental to OOP's core philosophy. The video delves into these distinctions, discussing how encapsulation and modularity, often seen as benefits of OOP, can be achieved in various programming paradigms without relying on strict object-oriented constructs. It challenges the common notion that classes are a prerequisite for OOP, highlighting that objects, as defined by various authors, are primarily about state retention and operation execution, not necessarily class instances. This deep dive aims to create a better understanding of OOP's true essence and its practical implications in software development.

What is an Object in Programming?

The concept of an object in programming is often misunderstood, especially when tied exclusively to languages like Java. When asked what an object is, many developers instinctively respond that "in Java, an object is an instance of a class." However, this definition is specific to Java and does not encompass the broader meaning of an object in general programming or computation. Different authors provide varying perspectives on what constitutes an object, none of which explicitly mention classes.

Peter Wagner will say that an object is a collection of operations that share a state. Markfield and Daniel Bob will say that objects are entities that combine procedures and data and store state locally. Gang of War will define that objects store data and procedures that operate on data; procedures, in this case, are usually called methods or operations.

These definitions highlight that objects are primarily entities that encapsulate both data (state) and the functions or procedures that operate on that data. The emphasis is on the combination of operations and shared state, allowing for self-contained units within a program. This aligns with Alan Kay's vision of objects as "cells" of a program, self-contained entities that communicate through message passing. The key takeaway is that an object's essence lies in its ability to manage state and execute operations, independent of whether it is instantiated from a class.

Alan Kay's Vision of OOP

Alan Kay, widely credited as the creator of Object-Oriented Programming, had a specific vision for what OOP truly means, distinguishing it from how it is often implemented in popular languages today. His definition emphasizes five core principles:

Message passing: Objects communicate by sending messages to each other, rather than directly invoking methods or accessing internal states.
Local retention: Each object is responsible for its own data and behavior, maintaining its state internally.
Protection and encapsulation of state/process: Objects hide their internal details, exposing only necessary interfaces to interact with.
Late binding: The specific method or function to be executed is determined at runtime, not compile time.

Kay's conceptualization of objects as "biological cells" further illustrates his vision. Just as biological cells interact and communicate, objects in a program should be self-contained units that interact by exchanging messages. This biological analogy underscores the dynamic and autonomous nature of objects in his original design. The fact that his definition does not explicitly mention classes, inheritance, or polymorphism is a crucial point, as these are often incorrectly assumed to be fundamental to OOP.

Late Binding Explained

Late binding, also known as dynamic binding, is a fundamental concept in Alan Kay's definition of Object-Oriented Programming. It refers to the process where the determination of which method or function will be called occurs at runtime, rather than during compilation. This means the compiler does not necessarily know which specific function will be executed until the program is actually running.

Consider an example with an Animal class and a Dog class that inherits from Animal, both having a "speak" method. When a function is designed to make an animal speak, and the specific type of animal (e.g., Dog or Duck) is determined at runtime—perhaps through user input or an external API—the compiler cannot know in advance which "speak" method (Animal's, Dog's, or Duck's) will be invoked. This runtime resolution is precisely what late binding achieves.

Crucially, achieving late binding does not necessitate the use of classes. While languages influenced by Smalltalk programming language often use classes to implement this, other paradigms can also achieve dynamic method dispatch. For instance, in Python, one could use dictionaries of methods to simulate polymorphic behavior without explicit classes. This demonstrates that classes are an implementation detail, not a core requirement for late binding or OOP as originally conceived.

The Influence of Simula and Smalltalk

The history of OOP is deeply intertwined with the development of specific programming languages. While ideas related to OOP emerged at MIT computer science in the 1950s, the Simula programming language, developed in Norway in the 1960s, was one of the first to introduce concepts like classes and inheritance in a dynamic fashion. Simula significantly influenced Alan Kay in his creation of the Smalltalk language at Xerox. Smalltalk, in turn, became highly influential in the world of computing due to its heavy reliance on classes and dynamic inheritance.

However, it's important to note that while Smalltalk used classes and inheritance extensively, Alan Kay's original definition of OOP never mentioned these specific concepts. Concepts like "polymorphism" were also absent from his core description. The pervasive use of classes and inheritance in Smalltalk led to these features becoming synonymous with OOP in later languages. Objective-C programming language, C++, and more recently Java, all adopted principles and patterns from Smalltalk, directly or indirectly. These languages inherited the implementation style of OOP prevalent in Simula and Smalltalk, despite OOP's foundational definition by Kay not requiring them. This historical progression explains why many developers associate OOP primarily with class-based inheritance and polymorphism, even though these are specific implementations rather than universal requirements.

Common Misconceptions of OOP

Many developers hold common misconceptions about what truly defines Object-Oriented Programming, often equating it with specific features found in popular languages rather than its core principles. When asked to define a language or codebase as "object-oriented," the most frequent responses include:

Objects
Encapsulation
Inheritance
Polymorphism
Classes
Modularity

However, if we refer to Alan Kay's original definition of OOP, only "objects" and "encapsulation" truly align with his vision. The other concepts, such as inheritance, polymorphism, and classes, became prominent due to the influence of languages like Smalltalk, which adopted these structures. These were implementation choices, not prerequisites for satisfying Kay's definition.

Furthermore, Alan Kay himself controversially stated that only Smalltalk and Lisp programming language are truly object-oriented languages. This suggests that his interpretation of OOP is far more stringent and unique than the broader understanding embraced by the industry. The prevalence of certain features in languages like Java has led to a narrow view of OOP, where the presence of classes and inheritance is seen as the defining characteristic, despite these not being central to the original concept.

Modularity and Encapsulation

Modularity and encapsulation are often cited as key benefits of Object-Oriented Programming, facilitating high cohesion and low coupling in software design. While they are often discussed in the context of OOP, these concepts are not exclusive to it and can be achieved in various programming paradigms.

Modularity

Modularity refers to the idea of structuring a program into independent, interchangeable modules. This is analogous to having an interface or protocol that defines how different parts of a system should interact, regardless of their underlying implementation. For example, a business logic layer might depend on a database layer through a defined API (e.g., CRUD operations), allowing the specific database implementation to be swapped out as long as it adheres to the same protocol. This promotes maintainability and flexibility, as changes in one module are less likely to affect others. Most modern programming languages, from Golang to Haskell, offer mechanisms for modularity, demonstrating that it's a general software design principle rather than an OOP-specific feature.

Encapsulation

Encapsulation, in an OOP context, typically means that an object's internal state is only accessible by the object itself, and interactions occur through public methods (getters and setters). This concept aims to prevent external components from directly manipulating an object's internal data, thereby reducing dependencies and promoting a controlled interface. Brad Cox, creator of Objective-C, sought encapsulation after recognizing the challenges of highly coupled code in C, where "everything is public." Proper encapsulation ensures that an object can change its internal implementation (e.g., how it stores or calculates an attribute) without affecting external code that interacts with it via its public interface.

However, problematic implementations, such as creating empty classes with simple getters and setters that merely expose internal state without any validation or complex logic, defeat the purpose of encapsulation. Such practices break the principle of hiding internal state, leading to "encapsulating nothing." Encapsulation, when properly implemented, contributes to high cohesion (keeping related elements together within an object) and low coupling (minimizing dependencies between objects). Both modularity and encapsulation contribute to robust, maintainable, and flexible software, and their benefits extend beyond the confines of object-oriented languages.

Inheritance, Polymorphism, and Classes

In the real world, when developers speak of Object-Oriented Programming, they typically refer to codebases characterized by inheritance in OOP, polymorphism in OOP, and classes in OOP. This interpretation is largely influenced by mainstream languages like Java, where the program structure heavily relies on classes with private methods and public functions. However, as previously discussed, Alan Kay's original definition of OOP does not necessitate these constructs.

Even prominent proponents of design patterns, such as the Gang of Four Design Patterns, advocate for "composition over inheritance," suggesting that it is better to combine simpler objects rather than relying on complex inheritance hierarchies. This preference for composition often leads back to the goal of modularity, as it encourages creating independent, reusable components that can be assembled as needed, rather than tightly coupled hierarchies.

Inheritance, polymorphism, and classes, while fundamental to many popular OOP implementations, can be viewed as specific forms of subtyping in programming, where a more specific type adheres to the specifications of a broader type. The Liskov Substitution Principle, for instance, emphasizes that if a program uses a base type, it should be able to substitute that type with a subtype without issues. This principle can be achieved through various mechanisms, not solely through class inheritance. Therefore, these elements are often considered optional or alternative ways to achieve the core principles of OOP, rather than being essential components themselves. The distinction between what OOP truly is and how it is most commonly implemented highlights the ongoing debate and diverse interpretations within the programming community.

Concept	Alan Kay's Vision	Common Interpretation (e.g., Java)
Objects	Self-contained "cells" that store state and handle operations; communicate via message passing.	Instances of classes capable of storing data (attributes) and performing actions (methods).
Classes	Not explicitly mentioned as a core requirement for OOP.	Fundamental building blocks; blueprints for creating objects.
Inheritance	Not explicitly mentioned as a core requirement for OOP.	Mechanism for creating new classes based on existing ones, inheriting properties and behaviors.
Polymorphism	Achieved through late binding; not explicitly mentioned with this term.	Ability of objects of different classes to respond to the same message/method call in their own way.
Encapsulation	Objects protect their internal state, exposing only necessary interfaces.	Hiding internal data and implementation details; access commonly controlled by public getters/setters.
Modularity	Achieved through self-contained objects communicating via messages.	Achieved through well-defined classes and packages, promoting separation of concerns.
Key Objective	High cohesion and low coupling through message passing and protected state.	High cohesion and low coupling typically through class design, interfaces, and design patterns.

Takeaways

OOP Misconceptions: Many developers misunderstand what Object-Oriented Programming truly is, often confusing it with specific implementations found in languages like Java, particularly focusing on classes, inheritance, and polymorphism.
Alan Kay's Definition: Alan Kay, the creator of OOP, defined it based on message passing, local retention, protection, encapsulation of state/process, and late binding. His definition does not explicitly mention classes, inheritance, or polymorphism.
Objects Beyond Classes: An object, in its fundamental sense, is something that stores state and executes functions, regardless of whether it is an instance of a class. Various authors support this view, emphasizing that objects combine data and operations.
Late Binding: This refers to resolving which method or function is called at runtime, not compile time. It can be achieved without classes, highlighting that classes are an implementation choice rather than a core requirement for dynamic behavior.
Modularity and Encapsulation: These concepts contribute to high cohesion and low coupling in software design and are not exclusive to OOP or class-based systems. They can be realized through various programming paradigms and organizational structures.
Composition Over Inheritance: Even proponents of design patterns suggest "composition over inheritance," indicating a preference for combining simpler objects rather than relying on complex inheritance hierarchies, which often aligns with achieving greater modularity.