Imagine building a house. You could gather bricks, glass, and timber and start building every wall, window, and door from scratch. This would eventually work, but it would be wasteful and labor-intensive. A better approach would be to use blueprints, divide the work into rooms, and maybe even pre-build some components like windows and doors. That is how object-oriented programming (OOP) works.
Instead of writing code as a single, long set of instructions, you break it down into smaller, self-contained units called “objects.” These objects can represent things like a “car” with properties like “color” and “speed” and actions like “drive” and “brake.”
Languages like Java, Python, and C++ use OOP. The big advantages are that you can reuse code, make changes more easily (since you’re only modifying specific parts), and build complex systems that are more organized and efficient. It’s like having a set of pre-built LEGO bricks — you can combine them in different ways to create all sorts of things.
Object-oriented programming
In the simplest mode, when we program something, we provide instructions for the program to follow — advance ten paces, turn right, and finally pick up the key. Setting up this simple set of commands is called “imperative” programming. An imperative program may have thousands of steps. In a program, these steps invariably work with data, creating, reading, changing, and deleting pieces of information as they execute each step in sequence.
The problem with imperative programming
It’s difficult to change
Consider a small start-up business that is nimble and flexible, able to change, add products and services, and improve quickly. But the larger it grows, the more staff, departments, and bureaucracy it adds, the slower and clunkier it becomes. Change is cumbersome, and the company cannot react to shifts in the market. An established imperative system is like a century-old corporation, firmly fixed in its ways, waiting for a young disruptor to unseat it.
Imperative languages are successful, and rightfully so. However, the larger and more complex systems become messier and more difficult for developers to track which commands are doing what with which data. A large imperative system is a monolith whose time-to-market increases until even replacing comes at great expense.
It doesn’t encourage code reuse
Imagine USB drives or web cameras that only work on a specific computer. The company manufacturing such products must keep a potentially infinite line or risk failure. Instead, most peripheral devices work on any computer. Companies like Cisco and Intel became successful because they produced devices and chips that worked on any PC. Reuse is crucial.
Imperative functions and routines use global variables. When executed, they change the state of the entire program, meaning they cannot be reused without fully understanding the side effects. This paradigm works well for a specific task but does not promote reuse.
Error-prone and difficult to read
The detailed, step-by-step nature of imperative code can make it harder to understand the overall logic, especially when dealing with complex control flows, leading to poor code maintainability.
Modifying variables directly can introduce unintended side effects, making it more likely to introduce errors when changing parts of the code.
How does object-oriented programming work?
Object-oriented programming offers a friendlier approach to the humans building and maintaining software.
When describing it, I prefer to think of it as a way of thinking rather than coding. We take things with something in common, such as commands and the data upon which they operate, and chunk them into recognizable entities.
In this way, software programs with their bits, bytes, and machine instructions become represented as real-world things and ideas.
Our list of instructions for advancing some paces before picking up a key and the status of having a key (or not) could be rolled together into a “robot” object. Now, every command or set of commands (the behaviors) and everything about the thing (attributes) represent a class of the thing — a “robot.”
Classes in object-oriented programming are user-defined data types that serve as blueprints for creating objects with specific attributes and methods.
Object-oriented programming concentrates code that would otherwise be redundant into “classes.”
For example, a class Person can serve as a superclass for students and professors, demonstrating inheritance and polymorphism by encompassing shared properties of individuals.
Let’s look at this concept in more detail. Object-oriented programming has four key characteristics:
- Encapsulation: Reduce complexity and increase reusability.
- Inheritance: Eliminate redundant code.
- Polymorphism: Hierarchies of things.
- Abstraction: Reduce complexity and isolate the impact of change.
Let’s talk about each.
Encapsulation and data hiding
Encapsulation is perhaps one of object-oriented programming’s most important features. Everything about an object — its attributes and behaviors — is wrapped up in a protective casing. No robot can see what the other is carrying (unless it chooses to reveal it), and none can issue commands to other objects (again, unless this is desired). Changes or commands issued to one robot do not affect another.
Encapsulation protects an object from unexpected side effects. It is also about storing data and protecting information — data fields can be marked as public or private.
In code, encapsulation involves wrapping data fields and methods in a single unit, usually a class, and restricting direct access using access modifiers. For example, private fields with public getters and setters.
A Java example:
public class Robot {
private String id; // private = restricted access
// Getter
public String getId() {
return id;
}
// Setter
public void setId(String newId) {
this.id = newId;
}
}
Inheritance
Inheritance is the process of creating a new class (child class) that inherits attributes and methods from an existing class (parent), thereby promoting code reuse. For example, a Car class inherits from a Vehicle class, taking all of its parent class's attributes and behaviors and adding some of its own.
A Python example:
class Animal:
def init(self, name):
# Storing the name of the animal
self.name = name
def sound(self):
return "I need a sound"
class Cow(Animal):
def sound(self):
# Cow-specific sound
return "Moo!"
In object-oriented programming, we call this an “is-a” relationship. A Car is-a Vehicle. A Cow is-an Animal.
Inheritance saves us from having to define a Cow class from scratch. We did not need to define the “name” attribute. We only needed to state that it inherits from the parent class, Animal. This is called a “has-a” relationship — a Cow “has-a” name.
Any programmer who adds more types of Animals to the program can do so by focusing only on the attributes and behaviors specific to that subclass, automatic reuse without repeating a line of code.
But while inheritance allows a new class to take on the characteristics of a parent class, sometimes we need to refine those characteristics or add entirely new ones — this is where derived classes come in.
A derived class is a subclass that not only inherits attributes and methods from its parent but can also introduce new properties and behaviors of its own. A derived class is a class that is created based on another class, known as the base class. It inherits the properties and behaviors of the base class while allowing modifications or extensions specific to its own needs.
In our farmyard example, we might have a base class Animal with common attributes like name and age and a method eat(). A derived class Horse can inherit these features but also introduce new attributes like speed and maneColor and specific behaviors such as gallop().
Polymorphism
From the Greek “poly,” meaning many, and “morph,” meaning form, “polymorphism” is the shapeshifter in object-oriented programming.
It allows methods to perform differently depending on the object they are invoked on. When two types share an inheritance chain, they can be used interchangeably without errors.
To extend our animal example:
class Sheep(Animal):
def sound(self):
# Sheep-specific sound
return "Baa!"
Calling the sound() method on any object that is inherited from an Animal will work. We can instruct all objects of the Animal class to sound(), and whether they are a Cow, a Sheep, a Goat, or a Pig, they will respond with a farmyard cacophony.
Abstraction
This is the process of hiding implementation details and showing only the essential features of an object. A concrete example is an electric doorbell — a device with a simple push-button interface.
When we press the button on a doorbell, we don’t care how its internal circuits or mechanisms work. We only need to know it has a button that (hopefully) makes a sound. We can replace a doorbell with any other on the market without needing to explain to friends, families, visitors, and (unfortunately) door-to-door salespeople how the new bell works.
Let’s go back to our farmyard and switch back to Java for the next example.
abstract class Animal {
public abstract void animalSound();
}
Abstraction allows us to define a class’ expected attributes and behaviors but leaves the details to the subclasses that implement it.
For example:
abstract class Animal {
public abstract void animalSound();
}
public class Dog extends Animal {
@Override
public void animalSound() {
System.out.println("Woof!");
}
public static void main(String[] args) {
Dog myDog = new Dog();
myDog.animalSound();
}
}
NOTE: In Java, you cannot instantiate an abstract class.
Object-oriented languages
Object-oriented programming enjoys the support of the world’s best-known and widely used programming languages. Let’s discuss some of these. These languages are not in any order. This is not a top-5.
Python
Python has risen from being an obscure language used by students, scientists, and tinkerers to include web and enterprise business applications. Python's crystal-clear syntax makes it easy to learn, yet its sophisticated native capabilities and huge range of libraries make it useful for even advanced engineers. Python is widely used in various fields, including data science, machine learning, web development, and automation.
Python supports object-oriented programming’s key pillars but is not exclusively object-oriented. It also supports functional programming and procedural programming paradigms.
Java
Java is one of the few programming languages known by name to even those outside software engineering. Java is widely used in enterprise applications and Android apps. Java code can run on any Java Virtual Machine (JVM), making it portable across a multitude of platforms.
C++
The mother of object-oriented programming languages, C++, is the successor to the ubiquitous C language and the forerunner of Java and Microsoft’s C#.
In C++, a class is a user-defined data type that serves as a blueprint for these objects. It contains data members and member functions that can be accessed by creating an instance of the class.
C++ excels as an object-oriented programming language due to several key features:
- Classes and objects: C++ allows the creation of classes and blueprints for objects, encapsulating data (attributes) and methods (functions) that operate on that data. This encourages modularity and reusability.
- Inheritance: Classes can inherit properties and behaviors from other classes, fostering code reuse and a hierarchical structure.
- Polymorphism: Objects of different classes can be treated as objects of a common base class, enabling flexibility and dynamic behavior for more adaptable and extensible code.
- Encapsulation: Data members of a class can be made private, restricting direct access and protecting data integrity, which enhances data security and reduces the risk of unintended modifications.
- Data abstraction: C++ allows for creating abstract classes that define a common interface without providing complete implementations, promoting a high-level view of objects and their interactions. These features, combined with C++’s performance and efficiency, make it a powerful and versatile language for building complex, object-oriented systems.
Smalltalk
Despite lacking widespread commercial success, Smalltalk has had a profound and lasting impact on software design. Smalltalk and the engineers who championed it pioneered ideas in object-oriented programming and design patterns that influence software engineering today.
At its core, Smalltalk is purely object-oriented. Everything in Smalltalk, including numbers, characters, and even code itself, is an object. Objects in Smalltalk interact through messages, analogous to message-driven architectures we see at the application or microservice level in today’s modern and cloud systems.
Smalltalk was instrumental in popularizing object-oriented programming, which has become a dominant paradigm in software development. Its emphasis on objects, classes, inheritance, and polymorphism laid the foundation for many modern programming languages. Many of the design patterns commonly used today, such as the Model-View-Controller (MVC) architecture, have their roots in Smalltalk.
Smalltalk’s influence can be seen in programming languages like:
- Java borrowed heavily from Smalltalk’s object-oriented concepts and syntax.
- Objective-C was directly inspired by Smalltalk and is used to develop applications for Apple’s macOS and iOS platforms.
- Python, while not directly derived from Smalltalk, shares some of its object-oriented principles and dynamic nature.
Objective-C
Objective-C is the main programming language used to write software for Apple’s OS X and iOS. It is an example of inheritance, borrowing from C and Smalltalk to provide object-oriented capabilities and a dynamic runtime.
The downsides
Object-oriented programming has many benefits but does have some drawbacks. One key concern is increased complexity. The concepts like inheritance, polymorphism, and encapsulation can make code harder to understand and maintain, especially for large projects. Overusing inheritance can lead to complex class hierarchies, making it difficult to trace code execution and understand object relationships.
Another downside is potential performance overhead. Method calls in OOP can be slower than direct function calls due to dynamic dispatch and virtual function tables. Object creation and destruction also add overhead. This can be a concern in performance-critical applications.
If not designed carefully, OOP can also lead to tighter coupling between objects. Changes in one object can ripple through the system, requiring modifications in other parts of the code, making it challenging to maintain and refactor larger projects.
Finally, some OOP concepts are an unnatural fit for certain types of problems that are more naturally expressed using functional or procedural approaches. For example, simple scripts or mathematical calculations are easier and more efficient to implement without the overhead of object creation and management.
When selecting a programming paradigm, one must understand that no one style is the best fit for all. Developers, engineers, managers, and CTOs must be judicious and select the best style for the job.
More detail — design patterns
Design patterns are reusable solutions to common problems in software design. They provide a standardized vocabulary and best practices for addressing recurring challenges and promoting code reusability, maintainability, and flexibility. In object-oriented programming, design patterns are categorized into creational, structural, and behavioral patterns.
Creational patterns
These patterns deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. They abstract the instantiation process, making the system independent of how its objects are created, composed, and represented.
- Singleton: Ensures a class has only one instance and provides a global point of access to it. Useful for managing resources like database connections or configuration settings. However, overuse can lead to tight coupling and make testing difficult.
- Factory method: Defines an interface for creating objects while allowing subclasses to decide which class to instantiate. Decoupling client code from specific concrete classes helps achieve loose coupling. The pattern is particularly useful when the exact type of object to create is unknown at compile time.
- Abstract factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes. It’s useful when you need to create multiple related objects that must work together, ensuring consistency and avoiding incompatible object combinations.
Structural patterns
These patterns compose classes or objects into larger structures while maintaining flexibility and efficiency. They focus on how objects are composed to form larger structures.
- Adapter: Converts a class's interface into another interface clients expect. An adapter lets classes that couldn’t otherwise work together because of incompatible interfaces to collaborate. It’s useful for integrating existing code with new systems or libraries.
- Decorator: Dynamically adds responsibilities to an object without sub-classing. Decorators provide a flexible alternative to sub-classing for extending functionality. They allow you to add or remove responsibilities at runtime.
- Facade: Provides a simplified interface to a complex subsystem. By providing a higher-level interface, a facade makes a complex subsystem easier to use and reduces dependencies between the client code and the subsystem.
- Composite: Composes objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. It’s useful for representing hierarchical data structures like file systems or organizational charts.
Behavioral patterns
These patterns identify common communication patterns between objects and realize these patterns. They focus on algorithms and the assignment of responsibilities between objects.
- Observer: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. Observer is useful for implementing event handling systems and maintaining consistency between related objects.
- Strategy: Defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. It’s useful when you need to switch between different algorithms at runtime.
- Template method: Defines the skeleton of an algorithm in a base class but lets subclasses redefine certain steps without changing the algorithm’s structure. The template method promotes code reuse and enforces a consistent algorithm structure.
- Command: Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. Command is useful for implementing menu systems, undo/redo functionality, and transaction processing.
Using design patterns offers several advantages: they provide proven solutions, improve code readability and maintainability, and promote code reuse. However, it’s crucial to select the appropriate pattern for the specific problem and avoid overusing them. Applying patterns where they are not needed can lead to unnecessary complexity. Understanding the intent and applicability of each pattern is key to effectively leveraging their benefits.
