Concrete Class vs Abstract Class
Concrete vs abstract class in OOP explained — instantiation rules, shared vs varying behavior, and a Java example with interview Q&A.
Expected Interview Answer
A concrete class is a fully implemented class that can be instantiated directly with `new`, while an abstract class may leave one or more methods unimplemented (declared `abstract`) and cannot be instantiated until a subclass provides those implementations.
Concrete classes give a complete blueprint: every method has a body, so an object created from them is immediately usable. Abstract classes exist to define a shared partial contract for a family of related types — they can mix concrete (already implemented) methods with abstract (must-override) methods, hold constructor logic, and carry instance state, which is something a plain interface historically could not do. A class hierarchy typically has one abstract base near the top describing “what all subtypes have in common” and several concrete leaf classes providing the type-specific behavior. Attempting `new` directly on an abstract class is a compile error in Java; only a concrete subclass that implements every abstract method can be instantiated.
- Abstract classes let you share common state and partial logic across subclasses
- Concrete classes are the buildable end product that client code actually instantiates
- The split forces a clear separation between shared contract and type-specific detail
- Compilers catch missing overrides early, before an incomplete object could exist
AI Mentor Explanation
A generic "Bowler" blueprint in a coaching manual describes shared duties — run-up, follow-through, appealing — but deliberately leaves the exact delivery technique unwritten, since a spinner and a pacer do it completely differently. You cannot send an athlete onto the field carrying only that unfinished blueprint; you need the finished "Off-Spinner" or "Fast Bowler" manual where every technique is fully written out. The unfinished manual is the abstract class, and the finished, fully specified role is the concrete class you can actually field.
Step-by-Step Explanation
Step 1
Spot the shared partial contract
Identify state and behavior common to a family of related types, plus behavior that must vary per subtype.
Step 2
Declare the abstract class
Mark the class abstract, implement the common methods, and declare the varying ones as abstract with no body.
Step 3
Extend with concrete subclasses
Each subclass provides real implementations for every abstract method it inherits.
Step 4
Instantiate only the concrete type
new is only valid on the fully implemented subclass, never on the abstract base.
What Interviewer Expects
- A precise statement of why abstract classes cannot be instantiated
- Awareness that abstract classes can hold state and constructors, unlike traditional interfaces
- A real example distinguishing shared vs varying behavior
- Knowledge of when to choose an abstract class over an interface
Common Mistakes
- Claiming abstract classes cannot have any implemented methods at all
- Confusing abstract classes with interfaces as interchangeable concepts
- Forgetting a concrete subclass must implement every inherited abstract method or itself be abstract
- Saying a concrete class cannot be extended further, which is false unless marked final
Best Answer (HR Friendly)
“A concrete class is complete and ready to use — you can create objects from it directly. An abstract class is intentionally incomplete: it defines shared structure for a group of related classes but leaves some behavior for subclasses to fill in, so you can never create an object from the abstract class itself, only from a finished subclass.”
Code Example
abstract class Shape {
String label;
Shape(String label) { this.label = label; }
// shared, already implemented
void describe() { System.out.println(label + " has area " + area()); }
// must vary per subtype - no body
abstract double area();
}
class Circle extends Shape {
double radius;
Circle(double radius) { super("Circle"); this.radius = radius; }
@Override
double area() { return Math.PI * radius * radius; }
}
// Shape s = new Shape("x"); // compile error - abstract
Shape s = new Circle(2.0); // OK - concrete subclass
s.describe();Follow-up Questions
- Can an abstract class have a constructor if it can never be instantiated directly?
- When would you choose an abstract class over an interface?
- What happens if a subclass does not implement all abstract methods?
- Can an abstract class implement an interface without implementing all its methods?
MCQ Practice
1. Which statement about abstract classes is correct?
An abstract class cannot be instantiated directly — only a concrete subclass implementing all abstract methods can be.
2. If a subclass of an abstract class does not implement all inherited abstract methods, what happens?
A subclass leaving abstract methods unimplemented must itself be declared abstract; only a fully implementing class is concrete.
3. What can an abstract class hold that historically distinguished it from a plain interface?
Abstract classes can hold instance fields and constructors, letting them carry real state — something classic interfaces could not do.
Flash Cards
Concrete class in one line? — A fully implemented class that can be instantiated directly.
Abstract class in one line? — A partially implemented class with at least one abstract method; cannot be instantiated directly.
Can an abstract class have state? — Yes — unlike a classic interface, it can hold fields and constructors.
Who can implement an abstract method? — A concrete subclass, which must override every inherited abstract method.