Computing & Software Codexery

Object-oriented programming

A programming paradigm based on interacting objects.

Object-oriented programming

Object-oriented programming (OOP) is a way of structuring code that centers on objects—bundles that combine data with the functions that operate on that data. In an OOP program, these objects communicate with each other. Because experts disagree on exactly which features define OOP, it’s often unclear whether a given language qualifies as object-oriented, and to what extent. Since programming paradigms aren’t mutually exclusive, a single language can belong to multiple categories, not just OOP.

The concept of “objects” in software first appeared in the late 1950s and early 1960s at MIT’s artificial intelligence group, where it referred to LISP atoms with defined attributes. Around the same time, Ivan Sutherland’s Sketchpad (1960–1961) used terms like “object” and “instance” in its glossary, though it focused on graphical interaction. In 1968, MIT’s AED-0, a version of ALGOL, linked data structures (called “plexes”) with procedures, foreshadowing what later became known as messages, methods, and member functions. During this period, data abstraction and modular programming were frequent topics of discussion.

Meanwhile, in Norway, Simula was developed between 1961 and 1967. It introduced core OOP ideas such as classes, inheritance, and dynamic binding. Simula was primarily used by researchers modeling physical systems, like ships moving through cargo ports, and is widely considered the first language to include the essential features of an object-oriented framework.

Influenced by both MIT’s work and Simula, Alan Kay began developing his own ideas in November 1966, eventually creating Smalltalk, a highly influential OOP language. By 1967, Kay was already using the phrase “object-oriented programming” in conversation. Though sometimes called the father of OOP, Kay has said his vision differs from how OOP is commonly practiced, and he has suggested that the computer science establishment didn’t fully adopt his concept. A 1976 MIT memo co-authored by Barbara Liskov listed Simula 67, CLU, and Alphard as object-oriented languages but did not mention Smalltalk.

In the 1970s, the first version of Smalltalk was built at Xerox PARC by Alan Kay, Dan Ingalls, and Adele Goldberg. Smalltalk-72 stood out for using objects at the language level and for its graphical development environment. It was a fully dynamic system, letting users create and modify classes while working. Much of OOP theory, such as multiple inheritance, was developed within the Smalltalk context.

OOP gained prominence in the late 1970s and 1980s. The Flavors object-oriented Lisp, started in 1979, introduced multiple inheritance and mixins. In August 1981, Byte Magazine featured Smalltalk and OOP, bringing these ideas to a broad audience. LOOPS, the object system for Interlisp-D, was influenced by Smalltalk and Flavors, with a paper published in 1982. The first OOPSLA conference in 1986 drew 1,000 attendees and helped consolidate Lisp object systems, eventually leading to the Common Lisp Object System. During the 1980s, some attempts were made to design processors with hardware support for objects in memory, such as the Intel iAPX 432 and the Linn Smart Rekursiv, but these were unsuccessful.

In the mid-1980s, new OOP languages emerged: Objective-C, C++, and Eiffel. Brad Cox developed Objective-C after using Smalltalk at ITT Inc. Bjarne Stroustrup created C++ based on his experience with Simula during his PhD. Bertrand Meyer designed Eiffel in 1985, focusing on software quality through a design by contract approach.

By the 1990s, OOP had become the dominant programming paradigm, especially as more languages adopted it, including Visual FoxPro 3.0, C++, and Delphi. Its popularity surged with graphical user interfaces, which used objects for buttons, menus, and other elements—Apple’s Cocoa framework for macOS, written in Objective-C, is a well-known example. OOP toolkits also boosted event-driven programming.

At ETH Zürich, Niklaus Wirth and his colleagues took a different approach with Modula-2 (1978) and Oberon (1987), which included object orientation, classes, and type checking across module boundaries. In Wirth’s design, inheritance is not obvious because he called it “type extension,” viewing the relationship from the parent down to the inheritor.

Many languages created before OOP was widespread have since been updated with object-oriented features, including Ada, BASIC, Fortran, Pascal, and COBOL.

The specific OOP features vary from language to language. Below are some common ones. Comparing OOP with other styles, such as relational programming, is tricky because there is no clear, universally accepted definition of OOP.

Encapsulation and information hiding can refer to several related ideas. Cohesion means keeping related fields and methods together. A field (also called an attribute or property) holds information (or state) as a variable.

field
Computer science / programming paradigm
known_for
Objects, classes, inheritance, encapsulation, and dynamic binding

Lore & Background

The idea of 'objects' in programming began at MIT in the late 1950s and early 1960s, where 'object' referred to LISP atoms with identified properties. Simula is generally accepted as the first language with the primary features of an object-oriented language. Smalltalk-72, developed at Xerox PARC by Kay, Dan Ingalls, and Adele Goldberg, was notable for use of objects at the language level and its graphical development environment. Much of OOP theory was developed in the context of Smalltalk. In the 1980s, OOP rose to prominence. The Flavors object-oriented Lisp introduced multiple inheritance and mixins. New languages like Objective-C, C++, and Eiffel emerged. In the 1990s, OOP became the main way of programming, especially with the rise of graphical user interfaces.

Reader's Guide

Object-oriented programming became the dominant programming paradigm in the 1990s, especially as more languages supported it and graphical user interfaces used objects for buttons, menus, and other elements. Its significance lies in providing a framework for organizing code around objects that encapsulate data and behavior, promoting concepts like encapsulation, inheritance, and modularity. However, the article notes that the definition of OOP is contested, and comparing it with other styles is difficult due to lack of a clear, agreed-upon definition. Supporters argue OOP makes code easier to reuse and intuitively represents real-world situations, while critics like Eric S. Raymond have written that OOP languages tend to encourage thickly layered programs that destroy transparency. Luca Cardelli stated OOP languages have 'extremely poor modularity properties with respect to class extension and modification' and tend to be extremely complex. Joe Armstrong, principal inventor of Erlang, criticized the implicit environment objects carry. The legacy of OOP includes its influence on many languages—from Ada and C++ to Python and JavaScript—and its role in shaping modern software development practices, though debates about its merits continue.

Origins and the Birth of the Acronym

Robert C. Martin, a software engineer and instructor, first laid out the foundational ideas behind what we now call SOLID in his 2000 paper titled Design Principles and Design Patterns. The paper specifically addressed the problem of software rot, the gradual degradation of code quality over time as systems grow and accumulate complexity. This naming gave developers a compact reference point for a set of guidelines that had already been circulating in the software engineering community. The pairing of Martin's theoretical groundwork with Feathers' linguistic shorthand created a framework that has since become one of the most widely recognized design philosophies in the programming world, bridging the gap between abstract design thinking and everyday coding practice.

The Five Pillars: Core Principles

The SOLID framework is built on five distinct principles, each addressing a different dimension of code design. The Single Responsibility Principle insists that a class ought to have a single, unique reason to change, keeping its scope tightly focused. The Open-Closed Principle calls for code to welcome new additions while resisting changes to what already exists, allowing behavior to grow without disturbing working logic. The Liskov Substitution Principle guarantees that derived classes can stand in for their base classes without breaking the program's expectations or violating established contracts. The Interface Segregation Principle prevents clients from being burdened with interface methods they never actually need. Finally, the Dependency Inversion Principle directs developers to build upon abstractions rather than concrete implementations. Together, these five rules form a cohesive philosophy that guides how classes, interfaces, and modules interact, ensuring that the resulting codebase remains comprehensible, adaptable, and resistant to the tangled complexity that plagues poorly structured systems.

Beyond Object-Oriented Programming

Although SOLID principles are most commonly associated with object-oriented programming, their influence reaches well beyond that paradigm. The same five guidelines form a core philosophical foundation for methodologies such as agile software development and adaptive software development, where the emphasis on flexibility, incremental change, and responsiveness to evolving requirements aligns naturally with the spirit of each principle. Even functional programming draws on the underlying ideas, as the goal of writing code that is understandable, flexible, and maintainable is universal regardless of the programming paradigm in use. This cross-paradigm applicability is what elevates SOLID from a mere set of OOP rules to a broader design philosophy. It speaks to a fundamental truth in software engineering: that the structure of code, how responsibilities are distributed, how dependencies are managed, and how extensibility is preserved, matters just as much as the language or paradigm chosen to express it.

Practical Impact on Code Quality

The true value of SOLID principles becomes apparent in the day-to-day realities of software maintenance and evolution. When a class carries a single, well-defined responsibility, writing unit tests becomes straightforward and modifying the class carries minimal risk of unintended side effects. The Open-Closed Principle reduces the likelihood of introducing new bugs, since adding features does not require altering code that already works correctly. The Liskov Substitution Principle provides a guarantee of predictability: swapping a base-class object for a derived-class object will not cause the program to fail. Interface Segregation keeps dependencies lean, so clients are never forced to interact with methods they do not need. Dependency Inversion loosens the coupling between modules, making it possible to swap implementations without rippling changes through the entire system. Collectively, these principles transform code from a brittle, monolithic artifact into a living, modular structure that teams can understand, test, and extend with confidence.

Frequently Asked Questions

What is Object-oriented programming?

OOP is a programming paradigm in which software is organized around objects—entities that bundle data and behavior together—and programs are built from those objects interacting with one another. It belongs to the broader field of computer science and language design.

What are the core pillars of OOP?

The paradigm is commonly associated with objects, classes, inheritance, encapsulation, and dynamic binding. That said, the exact feature set that defines OOP is debated, so a language can be multi-paradigm rather than purely object-oriented.

Is every programming language object-oriented?

No—classifying a language as strictly OOP is debatable because there is no universally agreed-upon checklist of required features. Many modern languages blend OOP with functional, procedural, or other paradigms in a single codebase.

More in Computing & Software 1-22

Spotted an error? Know more?

This is a living reference — every entry is fact-audited, and reader corrections feed straight into our audit queue. Suggest an edit · See this site's audit record

Comments

Loading…
Open in the interactive codex →