DEV Community: Flavio Rozendo

Object-Oriented Programming - The Four Pillars

Flavio Rozendo — Sat, 05 Oct 2024 20:10:56 +0000

We are back again to talk about object-oriented programming. In the first article, we talk about the history of the paradigm and some basic concepts. It's a good idea to read this article before this one, once the concepts showed there will be used to talk about the four pillars of OOP: Abstraction, Encapsulation, Inheritance, and Polymorphism.

Study Case

To better understand the four concepts, we will use an application written in Java. This case study simulates a real-world banking application to demonstrate how those principles work.
The code is on this GitHub repository.

Abstraction

Abstraction involves structuring our system into low and high-level components.
Low-level components are classes and objects close to what our application does. We can say that these components do the dirty work, dealing with requests, and changes, and sometimes coordinating a complex flow.
On the other hand, high-level components are classes that represent abstract concepts. They don’t have a specific function in the application but can be reused in different contexts, assisting the low-level components in their tasks.

In our study case, we have three classes that can represent the use of abstraction: BankAccount, IndividualAccount, and EnterpriseAccount. The class BankAccount represents a generic account, controlling all the balance updates and account changes, but it doesn't represent any specific account type. We have two low-level classes for account type: IndividualAccount for persons, and EnterpriseAccount for companies. These two classes are used across the application to execute user requests, using BankAccount as its basis.

A good OOP software is a balance between low and high-level classes. However, it’s important to note that there aren’t just two layers of components. We can have multiple layers, as many as needed for a well-structured design. A class that appears high-level from one perspective may be considered low-level from another. In the example we use above, InvididualAccount and EnterpriseAccount are low levels from the point of view of BankAccount. At the same time, these two classes are high-level components from the point of view of the other components in the application, once they are in a layer above them in our design.

Ultimately, the main reason for abstraction is to simplify the code, create more manageable and reusable classes, and hide complex functionality. A high-level class aims to make an object easy to use and understand.
A good design using abstraction separates what needs to be done from how it is accomplished. A low-level object understands what it requires from the high-level object but doesn’t need to know how it performs its tasks. This way, we create a layer separating the use of a code and its implementation. Also, if we make the right separation between those concepts, high-level classes hardly change, which makes maintenance easier.

Encapsulation

OOP is based on objects and the interactions between them. But we don't want to allow free communication between all objects, and sometimes we need to keep an object’s data, or part of it, hidden from the rest of our code. This process is known as Encapsulation.
Encapsulation can be used for different reasons. First and perhaps most important is security. As we know, an object is based on state (properties) and behavior (methods). Therefore, given its context, it must ensure its state is valid and consistent. When we hide some information, we want to control who can access and principally change the object’s state. If the state can be affected by anything, it could lead to mistakes that impact this object's integrity.

Again, the BankAccount class can give us a good example of encapsulation. We must reduce the objects that can update the user's balance, once a wrong update of this value can leave us with big issues. So, the balance property is private and the only way to update it is using the method updateBalance. This gives BankAccount control of the changes, and if any rule is broken, the class can deny the change.

Another benefit of Encapsulation is that it simplifies the code. We can hide complex algorithms, making only the object owner of the code aware of their implementation. The other objects don’t need to know details. They use the method provided, and how things work under the hood is irrelevant to them.
Note the Payment class in our study case. This class has the executePayment method, which interacts with the bank account object and is used by TransferPayement and DebitPayment classes. Those classes only call the method and don't know how it works. Of course, this is not the case with a complex algorithm, but introduces the idea of hiding details from external classes.

We use the access modifiers to achieve effective encapsulation. The most common are private, protected, and public. In a good code design, nearly all the properties should be private. In some cases, when we want to grant child classes access to some properties from the parent class, those properties can be protected. This ensures that no one can directly access the object state.
The public access modifier should be used only for methods, and only a small set of them, as we don’t want to expose all the object behavior. Those methods will act as a gateway, giving access to the object's current state and providing ways to change it.

Inheritance

Inheritance is a mechanism that enables us to share properties and methods. We can create a single code that will be reused throughout the application. Then we can create classes that inherit this code, allowing them to use and redefine it as necessary.
The class that inherits is known as a child class, subclass, or even derived class. The inherited class is known as a parent class, superclass, or base class.
A parent class usually represents something abstract, which allows further definitions by the child class. When inheriting from a parent class, a child class can do one of three things:

Use the parent code completely, without changes.
Reuse the parent code partially by mixing it with your code
Reset the parent code completely, and rewrite the behavior for its needs.

Inheritance can be done using an interface, a concrete, or an abstract class. The child class can also be concrete or abstract. However, an abstract child class cannot be instantiated by itself; it requires another class to inherit from it. A child class uses the override technique to modify the behavior of methods inherited from the parent class.

In our application, the classes that make deposits and withdraw use inheritance. DepositMovement and WithdrawMovement inherit from the interface Movement. The interface defines a contract and ensures a common behavior between components. The classes implement this interface, inheriting the method movementMoney. The classes BankAccount, IndividualAccount, and EnterpriseAccount are also examples of inheritance.

Problems

Inheritance is extremely powerful and useful. However, there are also some downsides.
First, it creates a strong dependency between parent and child class that can make changes and evolutions difficult. When the parent class is modified, all the child classes below it will be affected. The deeper the inheritance hierarchy, the more complex it becomes to change and maintain the code.
Another issue is that inheritance is defined at compile time, so once the bind between classes is done, it won't change. This makes the code inflexible.
Inheritance can also break or weaken the encapsulation since a child class can access more things than is desirable. Tests can also be hard when we have an inheritance.

Composition

Composition is a technique that allows a class to reference objects of other classes in its instance variables. This establishes a "has-a" relationship between the classes, where one class contains an object of another class. This can be a better option in situations where we can use inheritance.
Composition offers solutions to some of the challenges associated with inheritance:

We can change the behavior of a class at runtime by changing the object instance.
We can reduce duplication but with loose coupling between classes.
Avoid the hierarchy hell, and keep classes simple and modular.
It's easier to test, once we could change the instance used at runtime.
Promotes better encapsulation, once the class used in composition will expose only what it wants.

In our application, the Payment class uses composition. TransferPayment and DebitPayment don't inherit Payment. Instead, they use an instance to call the method on the base class.

Despite these benefits, inheritance should not be dismissed entirely. There are cases when it can be a good option:

When there is a clear “is-a” relationship, that is, when a class is a specialization of another.
When multiple classes share a significant amount of code, and you want to avoid duplication.
When we want to extend the functionality of a code that is external to our application, as a framework or a library

As always, it depends on the specific context. The better option will depend on the requirements and constraints of the project. Composition offers more flexibility and promotes better design practices. Inheritance can be appropriate for clear hierarchical relationships and shared behavior.

Polymorphism

Polymorphism is one of the fundamental pillars of OOP, and at least for me, the most difficult to understand and explain.
First, it's closely related to inheritance. When we work with inheritance, we create a hierarchy between classes, where a parent class has a set of child classes.
In this scenario, it is common for methods in the parent class to be reused by all child classes. But how can we have a single method that accepts any child class as a parameter? Polymorphism provides a solution to this challenge.
Polymorphism allows an object to be treated as an instance of its parent class or an implemented interface. This means we can have a method with a parent class or interface as its parameter, allowing it to accept any object of the child classes. So a single method to handle various objects as if they have a common type.

However, this approach has a limitation: methods defined outside the parent class or interface cannot be accessed. If a child class defines a new behavior, it will not be accessible through polymorphism.

There are two types of polymorphism. The first type, runtime polymorphism, occurs when a child class overrides a method from the parent class. With this, we can change the method's behavior on the child class during runtime. The second type, compile-time polymorphism, occurs when a child class overloads a method from the parent class. This changes the method’s behavior before the application starts.

Again, the classes BankAccount, IndividualAccount, and EnterpriseAccount can be used as examples, once they are good examples of polymorphism. Throughout the application, some methods use an object BankAccount as a parameter. However, the objects passed to those methods are IndividualAccount or EnterpriseAccount instances, and this only works because of their inheritance relation and polymorphism. Also, we have an example of compile-time polymorphism, once the method isDocumentValid is overridden in both concrete classes.

Polymorphism is an effective way to make code flexible, extensible, and easy to maintain, as it allows shared methods across an entire hierarchy of objects.

In the end, maybe this text became longer than I wanted it to. And I didn't go deeper at any of the four pillars. There is more to talk about and learn.
Also, the application used in the examples is to give you a concrete case of each pillar in a "real" application. When we work in production code, the challenges are more difficult, and the lines between good and bad code are thin. But if you understand these concepts, the path to good decisions may be clear.
I hope you enjoyed it! Thanks.

References:

Object-Oriented Programming - The Bases

Flavio Rozendo — Sat, 14 Sep 2024 22:11:14 +0000

Object Oriented Paradigm, or OOP, is a programming paradigm used on a large scale in the software industry. A lot of software we use is built in OOP, from social media to business applications.
This paradigm can be loved or hated, depends with who you are talking to. But no one can deny its importance. So, before understand more about OOP, let's talk a bit about programming paradigms.

Programming paradigm

A programming paradigm is a set of concepts and principles that define how we deal with and resolve problems. It refers to how a programming language organizes, stores, and manipulates data. Different paradigms may resolve the same problem using a different approach, but all of them can achieve the same objective.
The program paradigms might differ from each other in some aspects, such as the way code is organized, syntax, grammar, and even the way that the execution model works. They are the outcome of research and studies in computer science, incorporating widely used techniques from earlier practices.

The main programming paradigms currently are:

Object Oriented
Functional
Procedural
Imperative
Declarative

A programming language can implement more than one paradigm if they want to. For example, Java and Python work with more than one. However, some languages, such as Haskell, are binding to a specific one.

OOP History

Coming back to OOP, it’s difficult to determine a unique starting point. There were references to terms and techniques of OOP back in the 1950s and 1960s when groups of studies at MIT University already used terms as objects and instances. SIMULA is a programming language developed at that time and used some concepts used nowadays in OOP.
However, the first language considered OOP and used on a large scale was Smalltalk, with its first version launched in the 1970s. The real success of this paradigm only began between the end of the 1980s and the beginning of the 1990s. The launch of C++, a C language with support to OOP, was one of the triggers for this success.
Since then, OOP has been one of the most used paradigms in the world. A set of famous languages support it, such as Java, C#, Python, Javascript, Kotlin, and PHP.

How OOP Works?

OOP is based on objects. But what does this mean? To answer this question, it's common to say that objects represent things from the real world in software. Maybe this is not the best explanation so we will try a different one.
Let's get a bank account as an example. When we open an account, we have some informations about this account, such as agency, account number, and balance.
We also need to execute some operations, such as withdrawing, depositing money, paying bills, and receiving transfers from other persons.
So in the end, to represent an account, we need a set of data and behavior. And this is exactly what an object is. We can use our object to store the state, such as the account number and balance, and also define how we can manipulate our data and change this state.
In OOP, a computer program is nothing more than a collection of objects, and the software works from the interaction between those objects.
This paradigm has a lot of benefits, but in the end, the main objective is to make software that is easy to maintain, change, and grow. Before OOP, some software was too confusing to understand, making any change, even the small ones, very difficult. With objects, we group data that represent something and define the boundaries and rules for those data. With this, we achieve modularity, reusability, scalability, maintainability, and extensibility easier.

Basic Concepts

Now, let's go deeper into some technical concepts of OOP. Here I will use some code examples, based on Java language, but that could be adapted easily to any other language that supports OOP.

Classes

Classes, or concrete classes, can be defined as a template for objects. The goal is to create a reusable structure, defining fields and methods, that will be used to create as many objects as it needs. Here is an example of how to create a class:

public class CodeExample {
    int id;
    String name;

    public void save() {
       //more code
    } 
}

In a class, fields are where our object data is stored. Those data also define the state of an object. A class can have as many fields as it wants, without limitations, although a large class is difficult to handle. Fields can also be known as properties or attributes.
Otherwise, methods are the behavior side of a class. Methods define how the data of an object can be manipulated, and how an object state can change. As fields, methods don't have any limitations. In some languages, methods are known as functions.
A class can be extended by another one. This means it inherits all fields and methods and can add its own. In those cases, the class inherited is known as superclass and the class that extends is known as subclass.

Interfaces

Interfaces are contracts that define a specific behavior, saying what a class must do without saying how it does it. In the interface, we create what is called method definition, where we set the method name, parameters, and return types, without the implementation.
Once a class implements the interface, it must implement all those methods, following the definition of the interface.
More than one class can implement the same interface. With this, objects of different types can have the same methods, even with a different behavior.
In OOP an interface can't have fields and implement methods, and each class can implement just one interface. However, some languages broke this rule, allowing methods implementation on the interface, and multiple interfaces per class.

public interface OopInterfaceExaple {
    public void someMethod(int parameter);

    public double anotherMethod();
}

Abstract Classes

An abstract class is a mix between classes and interfaces.
This kind of class can define fields and methods as well. Besides that, as the interfaces, this class can create a method definition without creating the implementation. These methods are known as abstract methods.
Because of this behavior, we can't create an object from an abstract class.
To use an abstract class, we must extend this class with a concrete class. When we do that, as happens when a class implements an interface, we must define a concrete implementation for all the abstract methods.
We can have an abstract class extending another abstract class. However, we still can't create an object, even if the new abstract class implements all abstract methods.

public abstract class AbstractExample {
    public abstract int someAbstractMethod(); 

    public long someConcreteMethod(long a, long b) {
        return a + b; 
    }
}

Objects

We already discussed what is an object in OOP. But now that we know classes and interfaces, let's talk more, focusing on the technical part.
Objects are primary components of the OOP paradigm. They are instances of a class, which means they are a self-representation of the class.
We can make a parallel between software and architecture. When an architect creates a project, it defines how a house should be built, without building anything. With the project, we can create as many houses as we want. All the houses will have the same base structure but have no relation and can be different in some aspects, such as inside and outside color.
Objects and classes work the same. A class defines the fields and methods that the objects will have. With a class, we can create as many objects as we want. Those objects share the same structure, so they all have the same fields and methods. However the state of each object is individual, and they don't share data between them.
We can use the command new to create a new instance of an object.

SomeClass object = new SomeClass();

AnotherClass anotherObject = new AnotherClass(value);

Each object will be a set of fields and methods.

Fields

As we said more than once, a field keeps the object data and state. However not all the fields are the same, and they can hold different types of information. This can be different from language to language, but some types exist in almost all of them: int, float, double, char, and boolean.
Each type of field can hold a specific information. For example, int fields are for integer numbers, and boolean stores true or false.

Methods

Methods is where the action of an OOP application happens. Besides the possibility of changing the state of an object and manipulating their data, they also can call other objects, as long as they have an instance of this object they want to call.
A method can have parameters, which are values received when this method is called. There are no limits to how many parameters a method has, but the more they have, the harder it is to interact with them.
They can return a value as the result of its operation. Usually, a method can return only one type of value, but some languages allow the return of different types, and some more than one return at once.

someObject.makeSum(10, 5); 

someObject.printMessage("Hello OOP");

More concepts

Besides classes and objects, there are other important concepts to know before the next step.

Constructors

Constructors are special methods called when the object is created. They are used with the new keyword and called only once in the object lifecycle.
We use this method to set up the object on its creation, ensuring its state before using it.
We can have parameters on constructors, and some languages allow a class to have more than one. When this happens, each version must distinct on the number of parameters, or they should have different types.

public class SomeClass() {

    public SomeClass() {
        //init object state
    }

    public SomeClass(int value) {
        //init object state
    }

    public SomeClass(String message) {
        //init object state
    }

    public SomeClass(int value, String message) {
        //init object state
    }
}

Destructors

Destructors are also a special method but are the opposite of constructors. This method is called before the object is destroyed. As constructors, they are called automatically and only once on the object lifecycle.
With this method, we can perform cleanups and release resources used, such as memory, files, and network connections.
Not all languages implement this kind of method. Some languages work with garbage collectors to release resources instead of destructors.

Access Modifiers

Although the basics of any OOP application are the communication between objects, it's not desirable to allow full access to all methods and fields of any object. Sometimes we want to hide some fields and methods and allow access to only a set of objects, or even hide everything.
This behavior can be achieved with access modifiers. They can define the level of visibility of classes, methods, and fields. This way, we can control what we expose, how the state of an object can change, and who can change this state.
Again, this can be different from language to language, both in behavior and in existing types, but basically, there are four types of access modifiers:

public: there are no restrictions on access, fields or methods are accessible from anywhere.
private: allows access only inside the class where the method or field is defined, so they cannot be accessed directly from outside the class.
protected: members protected are accessible within the class in which they are defined and by subclasses.
default: some languages have default access if no modifier is provided, and the access is allowed just in the same package or something analog to this (namespace, assembly).

public class ExampleClass {

    private int someValue;

    public ExampleClass(int value) {
        int someValue = value;
    }

    protected int giveMeResult(int anotherValue) {
        return someValue + anotherValue;
    }
}

Overloading

Sometimes we need to do the same thing in different ways. In OOP we can do this using a technique called overloading.
Overloading allows us to have more than one version of the same method. In this case, we consider the same when the method name and the return type are the same. In overloading, we must have different parameters, either type or quantity, for each version of the method.
For example, we can create a printNumber method that takes an int value and prints it on the screen. We can also have another version that takes a long value. It's also possible to have a version that receives an int and a long, sum them, and print on the screen. The only thing different between all versions is the parameter types.

public void printNumber(int value) {
   //print the number
}

public void printNumber(long longValue) {
   //print the number
}

public void printNumber(int value, long longValue) {
   long result = value + longValue;
   //print the number
}

Overloading can be done in the same class, but a subclass can overload a superclass's method.

Override

Unlike overloading, override is when we change a method behavior, without changing the definition.
A subclass can override a superclass method, creating a method with the same name, parameters, and return type. This way, the subclass can change the behavior to its needs.
It's possible to completely override the method, or include his behavior, and then call the original method of the superclass, taking advantage of what exists there.

public class SuperExample {
    public void someMethod(long value) {
        //super class behavior
    }
}

public class SubExample extends SuperExample {
    @Override
    public void someMethod(long value) {
        //sub class behavior
    }
}

These are some basic characteristics of OOP paradigms, and there was already a lot to talk about. However, we will save the best for another post: the main pillars of OOP.
See you soon! Thanks!