Interfaces and Abstract Classes: The Continuous Learn/Unlearn/Relearn Journey - Evolution in Code Craftsmanship

After spending more than a decade in the industry, I've continuously embraced the evolution of concepts, learning, unlearning, and relearning. Today, let's deep dive into a widely used development topic: Interfaces and Abstract Classes. While numerous articles outline their differences, I aim to provide a WHEN-to-use perspective.

What is Abstract Class as a concept:

• An abstract class can have both abstract methods (methods without a body) and concrete methods (methods with a body).
• Abstract classes can have instance variables (fields).
• You can use the abstract keyword to define abstract methods within an abstract class.
• Abstract classes support constructors, and they can have a constructor that is called when a subclass is instantiated.
• A class can inherit from only one abstract class.

What is Interface as a concept:

• An interface can only have abstract methods (methods without a body) and constants (public static final fields).
• All methods declared in an interface are implicitly public and abstract.
• Fields in an interface are implicitly public, static, and final.
• A class can implement multiple interfaces.
• Interfaces cannot have constructors

When to use Interface?

Interfaces serve as the blueprint of a system, defining the contract that must be adhered to during implementation. It's like setting the ground rules for a game; if you want to be in the system, you've got to play by these rules. So, when you are confident about the rules and want to ensure uniformity in their implementation, interfaces are your go-to.

Imagine a scenario with vehicles. Every vehicle should have methods like start, stop, move, and brake. Additionally, it should provide methods to get the speed, fuel, chassis, gear, and more. These methods form the essential behavior of a vehicle in the system. Each vehicle must incorporate these methods, creating a standardized approach. However, since you might not be certain about the exact implementation of these methods, concrete classes can take care of those details.

In essence, interfaces are your tool when you're clear about the system's rules and want to guarantee that all implementations follow the same set of rules. They lay down the guidelines, leaving the detailed implementations to the concrete classes that make up the system.

When to use Abstract class?

While an Interface establishes the rules of the game, an Abstract Class determines not only the rules but also how the game is played. It's the arena where you not only define the game's rules but also lay out the implementation details and the sequence in which these rules should be executed.

Let's consider the example of a vehicle. In the case of starting and stopping, there's a specific process that unfolds in a certain order. First, you start the engine, then you engage the gear, followed by releasing the brake, and so on. The Abstract Class is where you articulate this sequential process.

In essence, if you are confident about the game's rules, certain about how they should be implemented, and wish to dictate the order of the processes, the Abstract Class is your choice.

So, when you're orchestrating not just what the rules are but how the game is played, and in what order, the Abstract Class becomes the tool of choice.

Conclusion

In summary, interfaces establish the rules of the game, ensuring adherence, while abstract classes define how the game is played, including the specific implementation and order of actions.

#softwaredevelopment #craftsmanship #development #learningandgrowing #architecture #learn_unlearn_relearn