DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication
  • AI and Cybersecurity Protecting Against Emerging Threats
  • The Dark Side of DevSecOps and Why We Need Governance Engineering
  • Part 3 of My OCP Journey: Practical Tips and Examples

Trending

  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication
  • AI and Cybersecurity Protecting Against Emerging Threats
  • The Dark Side of DevSecOps and Why We Need Governance Engineering
  • Part 3 of My OCP Journey: Practical Tips and Examples
  1. DZone
  2. Coding
  3. Java
  4. How to Choose Between Interface and Abstract Classes in Java

How to Choose Between Interface and Abstract Classes in Java

Get the answer to this frequently-asked core Java interview question.

Anant Mishra user avatar by
Anant Mishra
CORE ·
Dec. 05, 18 · Analysis
Like (20)
Save
Tweet
Share
37.70K Views

Join the DZone community and get the full member experience.

Join For Free

In Java, we have interfaces and abstract classes. When it comes to choosing which one, we give arguments like choosing interfaces that support multiple inheritances or choosing an abstract class that provides the implementation of a few methods in your parent class (though from Java 8 onward, we can give default method implementation in interface also). Visit when-to-use-abstract-class-and-interface for more details.

This is a famous and basic interview question related to core Java, and the explanation above holds true.

Why Do We Need a 100 Percent Abstract Class?

Now, this question is really important, because based on the above explanations, a 100 percent abstract class is not at all useful, because it doesn't provide a default implementation of methods nor does it support multiple inheritances.

So can we say that we should never create a 100% abstract class, or we are missing something here?

Let’s dive deeper to understand this better. We will take the example of creating a car and decide which interfaces and abstract classes are required.

What Is an Abstract Class?

Abstract means that something is not fully concrete — it’s merely an idea or gist of something. So when we talk about abstract classes, it means a class that does not have a concrete implementation in itself. This is just a structure or guideline created for other concrete classes. We can say that an abstract class is the soul of a concrete class. This is the reason we “extend” abstract classes. An abstract class should only have those properties and methods, without which a concrete class can't exist.

This is the reason Java does not support multiple inheritances for abstract classes. Because one concrete class can behave (or take all properties) of only one abstract class (and obviously, a body can’t have two souls).

For example, Man and Car have many common behaviors, like movement, creating sound, etc., but a Car class can only behave like a Vehicle, not as a human, and the Man class can only behave like a human, not a vehicle.

I agree that the above example is lame, but even in real life scenarios, if you are not sure which abstract class you should inherit or you think there is a need to inherit more than one abstract class, then this is a design smell, and you should revisit the design of your project.

Based on what we have discussed above, we need to create a Vehicle abstract class. This abstract class will have properties like Engine, Shape, etc. of Car and related methods. We added  Engine and Shape in the abstract class because no vehicle can exist without these two.

abstract class Vehicle {
  private String engine;
  abstract void startEngine();
  abstract void stopEngine();
}


What Is an Interface?

An interface is a behavioral contract between different systems. In Java interfaces, we define the behavior of a class, which will implement this interface. One class can have a number of different behaviors, that is why Java allows us to “implement” N number of interfaces. Interfaces are meant to provide only behaviors. This is why the Java naming convention suggests using adjectives as the name of an interface.

For example, a car can move, so we can create a movable interface and implement it in our Carclass. It is the same for drift and honk behavior. These are the behaviors of the Carmethod, not inbuilt properties. A Car will be car, even if it is not able to move.

interface Movable { 
  void move();
}


The sad thing is that we are habitual of using interfaces at the level where we nearly forget the power of abstract classes, their use, and the intention behind creating them.

Dummy Java Code Related to Car Class Creation

class Car extends Vehicle implements Movable {

  @Override
  void startEngine() {
    System.out.println("starting car's engine");
  }

  @Override
  void stopEngine() {
    System.out.println("stoping car's engine");
  }

  @Override
  public void move() {
    System.out.println("moving car");
  }
}


Summary

Key takeaways related to abstract class creation:

  • Create an abstract class when you are providing guidelines for a concrete class.
  • Abstract class creation is not at all related to whether you want to provide the implementation of any method or not.
  • Add only those properties and behaviors to the abstract class, without which your concrete class will lose its existence. For example, the Vehicle cannot exist without an engine.

Key takeaways related to interface creation:

  • Create interfaces that provide additional behavior to your concrete class. When we share these interfaces to the external system, then it becomes a contract, that is why we say that interfaces are behavioral contracts of the concrete class.
  • These behaviors should not be mandatory for your class. These behaviors should add more capabilities to your class. For example, a Car will be a Car, even if it cannot move.
  • Ask the question that, whenever a concrete class will implement your interface, will it require all behaviors mentioned in your interface, or only a few? Refactor your interfaces in multiple interfaces, until the answer to the above question is yes.

Thanks for reading!

Interface (computing) Java (programming language)

Opinions expressed by DZone contributors are their own.

Trending

  • How to Use an Anti-Corruption Layer Pattern for Improved Microservices Communication
  • AI and Cybersecurity Protecting Against Emerging Threats
  • The Dark Side of DevSecOps and Why We Need Governance Engineering
  • Part 3 of My OCP Journey: Practical Tips and Examples

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: