Object-Oriented Programming Concepts

Object-oriented (OO) programming is a programming paradigm that includes or relies on the concept of objects, encapsulated data structures that have properties and functions and which interact with other objects.

Objects in a program frequently represent real-world objects — for example, an ecommerce website application might have Customer objects, Shopping_cart objects, and Product objects. Other objects might be loosely related to real-world equivalents — like a Payment_processor or Login_form. Many other objects serve application logic and have no direct real-world parallel — objects that manage authentication, templating, request handling, or any of the other myriad features needed for a working application.

History of Object-oriented Programming

If it seems like object-oriented programming is particularly well suited to modeling real world systems, that isn't a coincidence. The concepts now associated with object-oriented programming, including most of the language for describing it, originated with the Simula programming language, which was used for simulating real world systems. Classes, subclasses, and objects were added to Simula in 1967.

In the 1970s, Alan Kay coined the term "object-oriented" while working on Smalltalk. This was in reference to the extensive use of objects in the language, and their place as the fundamental unit of organization.

The spread of object-oriented programming was relatively slow at first. Common Lisp introduced the Common Lisp Object System, adding objects to Lisp, in the late 1970s. In the 1980s, the Eiffel programming language was invented, which was fully object-oriented. The inventor of Eiffel, Bertrand Meyer, wrote Object-Oriented Software Construction, which was one of the first books to widely disseminate the concepts of OO programming.

In the 1990s and into the 2000s, object-oriented programming really took off. This coincided with a massive explosion in the tech industry generally during that period, and the sudden influx of programmers into large tech companies. One of the selling points of object-oriented programming, as promoted by its advocates, is that separation of concerns and loose coupling (see below) enable teams to work on large systems more effectively.

By the end of the first decade of the 21st century, object-oriented programming had largely become the accepted "one right way" of developing most software. Newer programming languages, especially dynamically-typed interpreted languages like Python, Ruby, and JavaScript, tend to assume, or even enforce, an object-oriented approach. Meanwhile, many older languages, like Fortran and COBOL have added object-oriented features.

Important Object-oriented Concepts

Object-oriented programming is a concept — a way of approaching the problem of designing a computer program. It is not a hard-and-fast set of rules or a specific methodology. Different programming languages approach OOP differently. Some are more or less strict, and some are just different. What follows is a general overview of object-oriented design concepts. See our sister article, Object-Oriented Programming for resources and details that explain how these concepts are implemented in many different languages.

Separation of Concerns

The central guiding principle which informs all the other concepts in object-oriented programming is separation of concerns. This is the idea that logically distinct bundles of data and functionality should be separated into distinct bundles of application code.

This idea is not unique to object-oriented programming. Most programming languages allow for separation of concerns, and most programming paradigms promote it. However, separation of concerns is of special importance to object-oriented programming. Strong separation of concerns is the impetus behind nearly all other OO concepts.

Objects and Classes

It seems, at first, that the fundamental concept in object-oriented programming is objects. In a way, that's true. But from the developer's perspective, the fundamental concern is classes.

A class defines an object; an object instantiates a class. For an example, let's keep thinking about an ecommerce website. There are a lot of customers, but they all do the same thing. So there would be a Customer class, in which the programmer defined what a customer is, and how it works. Then, each individual customer is represented in the system by a customer object.

Since class definitions specify all the implementation details, most of the work of developing an object-oriented program involves working with classes, not objects.

Classical and Non-classical OO Languages

There are a handful of languages which incorporate a large number of object-oriented concepts, but which don't have a construct specifically called a class. Most notable is JavaScript, which uses prototypes, or generic objects which are then cloned. The terminology, the underlying philosophy, and even the "under the hood" implementation are different — and yet the developer experience is largely the same.

Languages with classes, which represent the majority of OO languages, are sometimes called "classical." This is both a pun on the word "class," and an acknowledgement that classes have become the conventional approach to object-oriented programming.

Methods and Properties

An object has variables, which are usually called properties or attributes in most languages. For example, a Customer object might have properties like shipping_address or name.

Objects also have functions, called methods. These are things that the object is capable of doing, and are also defined within the class. For example, the Customer object might have methods for checkout, change_shipping_address, or logout.

One of the challenges of developing good object-oriented programs is determining how to split up functions among several potential classes. For example, should a checkout method belong to the Customer or to the Shopping Cart? Does the Customer own the logout method, or does the Customer call the logout method of some Authentication_manager object?

Another challenge for many new OO programmers is understanding how to design classes that don't represent real-world things. Understanding that ecommerce needs Products and a project management system needs Projects is pretty easy. But large object-oriented programs have countless classes defining all sorts of abstract bundles of functionality, like object relational mappers, object factories, and controllers (just to name three easy-to-understand examples).

Navigating these concerns takes practice, of course. An object-oriented developer can also be aided by an understanding of design patterns, and by a development process that includes modeling.

Here are a few resources to help you better understand class, properties, and methods:

Message Passing and Dynamic Dispatch

Classes, and a number of other concepts covered here, have become inexorably linked to object-oriented programming. However, according to the computer scientist who coined the term, object-oriented programming is about message passing.

Message passing means that objects communicate with each other by sending messages. This sounds trivial, but it affects how function calls are made. Rather than one object calling another object's functions directly, an object would pass a message to another object. The message contains a method name and any associated parameters. The called object then has the ability to handle that method call however is needed.

This ability for each object to determine its own response to method calls as needed is called dynamic dispatch. It allows objects to evolve over run time, and respond to messages according to their present state.

Message passing can be a little confusing, especially since most languages in use today only implement one particular kind (the method call). Here are a few resources to help you better understand it:


Closely associated with message passing and dynamic dispatch is the concept of encapsulation. Encapsulation means that code outside of an object cannot directly access its internal data. If, for example, one object needs to "know" a property of another object (for example, a Shipping_manager might need the shipping_address of a Customer object), then the calling object can't find that data out directly; it has to pass a message "asking" the Customer object, which then returns the needed data. (This is usually done with a method call.)

Not all object-oriented languages enforce strict encapsulation; some allow an object's properties to be accessed (get and set) directly. However, many experts in OO development encourage programmers to adhere to encapsulation principles (by not calling properties directly), even in languages that allow it.

There are many benefits to encapsulation. Primarily, it allows any details or side effects to be abstracted away from the point at which the property is called. For example, each time a particular value is read, you might want to check when it was last calculated, and re-calculate it if certain conditions are met. Being able to add, remove, or change that logic in one place at any time, without affecting any of the other places in the code which make the call, is a benefit of encapsulation.

Inheritance and Composition

Inheritance and composition are two ways that various classes (and their instantiated objects) are related to each other.

Inheritance describes "is a" relationships: a User is a Person; a Customer is a User. In this example, there might be a Person class which defines all the properties and methods of Persons in general (name, birthday). Then a User class would extend the Person class, to add things like a username attribute or login and logout methods. A Customer class might then extend User, adding those things that only a customer needs, like order_history or billing_address.

Composition describes a "has a" relationship, when one object "owns" another object. For example, the Customer class might own a Billing_address, which is itself a full-fledged object defined in a class. Like the inheritance hierarchy, the compositional hierarchy can easily be several layers deep. For example: a Customer might have a Shopping_cart, the Shopping_cart has several Products, each Product has a Vendor, and so forth.

Much of the design work in object-oriented development has to do with mapping out these relationships of inheritance and composition. The class diagram, which is a part of the Unified Modeling Language is an invaluable tool for visualizing these relationships.


Polymorphism (or, more specifically, subtype polymorphism) is a concept that naturally comes out of inheritance. If a parent class (or "Super class") has a particular method, then all of its children ("subclasses") will also have the method. Each subclass might implement the method differently, but calling objects do not need to know which of several subtypes they are calling. They can treat all different subtypes of objects as equivalent.

Polymorphism is a big subject, and is not without controversy. Here are a few resources to help wrap your head around it:

Learn More About Object-oriented Programming

For a deep understanding of object-oriented programming, a number of classic and contemporary books on the subject are invaluable, and can hardly be replaced by online tutorials.

For a more practical, and contemporary, understanding of object-oriented programming concepts, try one or more of these online resources:

Object-oriented Programming Today

While object-orientated programming remains an important methodology in computer programming, it no longer holds its place as industry standard for "good software development." Other paradigms, especially functional programming, are coming to the forefront, along with new languages that support them. Meanwhile criticisms of object-oriented programming, as well as of the design patterns movement, are on the rise.

Still, a large amount of the software written today is object-oriented. If you are working in any of the common object-oriented languages, you need to have a good understanding of basic object-oriented concepts.

Further Reading and Resources

We have more programming guides, tutorials, and infographics related to coding and development:

  • Object-Oriented Programming Languages: this is the sister article of Object-Oriented Programming Concepts. In addition to a brief introduction to object-oriented programming, it gives you an introduction to 14 object-oriented languages.
  • C++ Developer Resources: in addition to information about C++, there is more information about object-oriented programming.
  • Linux Programming Introduction and Resources: although not specifically about object oriented programming, this discussion of the many levels of Linux programming is bound to energize you.

What Code Should You Learn?

Confused about what programming language you should learn to code in? Check out our infographic, What Code Should You Learn? It not only discusses different aspects of the languages, it answers important questions such as, "How much money will I make programming Java for a living?"