Let’s Do It PL

What is “Abstraction”? What are the differences between Abstract Classes and Interfaces?

Abstraction is another important principle of Object-Oriented Programming. When developers code, they always seek tidiness and another way to achieving that is Abstraction.

Let’s say we will build a building but there are a lot of phases before the start. One of them is creating a plan for the building. An architect creates a plan, draws a blueprint of the building in detail, and engineers start to build depending on that blueprint. Even the building is finished, that blueprint is useful for adding new features to that building or fixing any kind of damage later.

Developers actually do the same thing in coding. They plan first, then create some related objects and connect them. It is why we are also called engineers in the real world. The question is: Do we also creating a blueprint? Yes, we are and the Abstraction principle steps in here. We are creating blueprints by creating Abstract Classes and Interfaces to classify our objects, writing cleaner codes, and getting information about the object we seek.

Let’s firstly talk about is it needed or not. An engineer can build a building without looking at the blueprint. He/she can just decide numbers and design by himself and finish it well enough. But we are all humans and it is highly possible to make mistakes or wrong calculations. Also, on every new floor, these will be less findable because it will be more information to remember. You can still manage to finish but doing with a blueprint helps us to avoid these problems or handle them.

Also after the building is finished, people who live inside it knows what is for what but they have no idea what is the inner mechanism or what is the logic of some parts of that building. So if we create a sentence about developing;

Abstraction is a mechanism for creating a blueprint of our code, grouping our objects and hiding irrelevant details of them.

Abstraction is simply obtained by creating Abstract Classes and Interfaces. Let’s check what they are.

“abstract” Keyword

Let’s check what is “abstract” keyword first. “Abstract” is used for a thing existing in thought or in an idea but not having a physical existence. That's just what we do in Abstraction. We creating classes and defining some methods but we are not using these methods by that class. We inherit them and make subclasses override their methods with force. So Abstraction is very related to the Inheritance principle.

Abstract Classes

Abstract Classes are special classes that can have abstract methods inside. Abstract methods are the methods that have no code body. Let’s see that in an example and explain that example.

public abstract class Car {

    public abstract void accelerate(int amount);
    public abstract void slowDown(int amount);
    public abstract void stop();
    
    public void openMusic(String musicName){
        System.out.println("Playing right now: " + musicName);
    }
}

We have an Abstract Class named Car and we have 4 methods. As we can see 3 of these 4 methods are abstract. These methods only have a declaration plus they don’t have any code body. Is that capable to manage any action? No, right? The functionality of a method decided inside its code body but they don’t have any. Then how can we use that method? Let’s inherit that Abstract Class.

public class Audi extends Car{

    private int currentSpeed;

    public Audi() {
        currentSpeed = 0;
    }

    @Override
    public void accelerate(int amount) {
        currentSpeed += amount;
    }

    @Override
    public void slowDown(int amount) {
        currentSpeed -= amount;
    }

    @Override
    public void stop() {
        currentSpeed = 0;
    }
}

We created a class named Audi that extends our Abstract Class named Car. When a class inherits an Abstract Class it MUST override these methods otherwise compiler throws an error. So if we create an Audi object, that object must have accelerate(), slowDown() and stop() methods but openMusic() method is exception. Because it is not abstract it is just a method in the superclass. Whenever we create a class that has common features as Audi, like Ferrari, we can extend the Car class so we can implement easily these methods to that class too.

So we created a blueprint of Car and whenever we create an object kind of Car, we can just extend it and we can see which methods we should create first. There is no car that cannot accelerate in the real world so engineers should implement that function in any kind of car when they build that car. So we are simply doing the same thing with listing common features of objects we want to create.

Interface

Interfaces are used for achieving Abstraction like Abstract Classes but in a different way. They have some differences and similarities but let’s focus on what is interface first.

Interfaces are not counted as a class, it is a different reference type. We can define them as a collection of abstract methods. They cannot have any other class than abstract methods or any variables. Let’s create one to check its syntax.

interface ICar {
    void accelerate(int amount);
    void slowDown(int amount);
    void stop();
}

That’s it! All methods inside an Interface are “public abstract” as default. We don’t need to declare them. If we do, it will give you a warning but not throw an error. Also, developers put an “I” letter before the name to understand it is an interface, not a class. Let’s inherit this interface.

public class BMW implements ICar{

    private int currentSpeed;

    public BMW() {
        currentSpeed = 0;
    }

    @Override
    public void accelerate(int amount) {
        currentSpeed += amount;
    }

    @Override
    public void slowDown(int amount) {
        currentSpeed -= amount;
    }

    @Override
    public void stop() {
        currentSpeed = 0;
    }
}

There is one big difference inheriting Interfaces, the “implements” keyword. We used the “extends” keyword when inheriting Abstract Classes but when inheriting Interfaces we should use “implements”.

Rules of Abstraction

There are some rules for using Abstract Classes and Interfaces.

• An abstract method can be only in Abstract Class or Interface.
• Abstract Classes or Interfaces cannot be instantiated. In other words, we cannot create an object of Abstract Classes or Interfaces.
• A class can only extend one Abstract Classes at the same time. Multiple Inheritance is not allowed.
• A class can implement infinite different Interfaces at the same time. Multiple Inheritance can be achieved only by using Interfaces.
• Interfaces can extend other Interfaces but cannot extend an Abstract Class. We used the “implements” keyword when inheriting an interface but if an interface inherits another interface it uses “extends” keywords. We use the “implements” keyword only when a class inherits an interface. For example;

interface I3{

}
interface I2 extends I3{

}
interface I1 extends I2{
    
}
public class C1 implements I1{
    
}

• Abstract classes cannot extend any Abstract Classes or Interfaces.
• Interfaces cannot have non-abstract methods (concrete methods).
• Interfaces cannot have any access modifier other than “public”.
• Interfaces cannot have a constructor.

Interfaces vs Abstract Classes

There are many differences between Interfaces and Abstract Classes. Let’s check deeply one by one:

Multiple Inheritance

As we said above, Multiple Inheritance is only obtained by interfaces. A class cannot extend more than one Abstract class but can implement infinite Interfaces. Let’s say we have Abstract Classes named AC1, AC2 and Interfaces named I1, I2, I3, I4.

public class SubClass extends AC1 implements I1,I2,I3{
    //inherited abstract methods
}

SubClass extends 1 Abstract class and 3 Interfaces at the same time. We cannot add AC2 near to AC1 because it is not allowed. On the other hand, we can add I4 or remove any other Interfaces that are implemented.

Structure

Abstract Classes can have methods other than abstract methods but Interface cannot. All methods inside Interfaces defined “abstract” as default.

Access Modifiers

Interfaces do not allow any access modifier inside. Every method inside of an Interface is “public” as default. But Abstract method is allowed to use any access modifier for its fields. Abstract methods inside Abstract Classes can be protected or public.

Data Fields

Interfaces cannot have any data fields like variables or constants. Abstract Classes can have.

Implementation

Adding a new method inside to Interfaces can be very problematic. All classes that implement immediately throws errors and until all subclasses override that new method, the program will not work. But working Abstract Classes is freer than Interfaces because Abstract Classes does not restrict all methods to be abstract as default like Interfaces.

When We Should Use Which One?

We understand that they simply exist for achieving Abstraction, but in detail, they have different usage and place of use. We should know which one is better when, otherwise it might cause some unintended problems.

• If we want to declare non-public methods inside the base class we should use Abstract classes because Interfaces cannot have any other class than public abstract ones.
• If we want to achieve functionality across a wide range of different object types, we should use Interfaces. Interfaces are usually used for providing common functionality across different classes that implement them.
• If we want to use group up objects that have similar attributes, we should use Abstract Classes. Abstract Classes are usually used for providing common functionality across similar classes that extend them.
• If we foresee making changes later, using an Abstract Class is a better choice than using an Interface.
• If we want to achieve Multiple Inheritance, we must use Interfaces because Abstract Classes cannot allow it.
• Interfaces are used for small designs. Classes achieve few functionalities by extending only an Interface. To achieve more functionality, more interfaces can be implemented to a class.
• Abstract Classes are used for large designs. Classes achieve many functionalities by extending only an Abstract Class.

By knowing these points we can decide which one fits better for our program.

Conclusion

Encapsulation and Abstraction are principles that complete themselves. By Encapsulation, we achieve data hiding and by Abstraction, we achieve implementation hiding. With these 2 principles, the security of our code highly increases as only important details are provided to the user. Also, like by using other Object-Oriented Programming principles, we achieve less complex, cleaner, reusable codes and we avoid duplication.