Bird
Raised Fist0
Javaprogramming~5 mins

Abstract vs concrete classes in Java - Performance Comparison

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Time Complexity: Abstract vs concrete classes
O(1)
Understanding Time Complexity

Let's explore how using abstract and concrete classes affects the time it takes for a program to run.

We want to see how the program's steps grow when we use these classes.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.


abstract class Animal {
    abstract void sound();
}

class Dog extends Animal {
    void sound() {
        System.out.println("Bark");
    }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.sound();
    }
}
    

This code defines an abstract class and a concrete subclass, then calls a method through the abstract reference.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

  • Primary operation: Calling the sound() method once.
  • How many times: Exactly one time in this example.
How Execution Grows With Input

Since the method call happens once, the time does not grow with input size.

Input Size (n)Approx. Operations
101
1001
10001

Pattern observation: The time stays the same no matter how many objects or calls you might have in a bigger program.

Final Time Complexity

Time Complexity: O(1)

This means the program takes the same amount of time regardless of input size when calling methods on abstract or concrete classes.

Common Mistake

[X] Wrong: "Using abstract classes makes the program slower because of extra steps."

[OK] Correct: Calling methods through abstract classes uses normal method calls and does not add noticeable time compared to concrete classes.

Interview Connect

Understanding how abstract and concrete classes affect performance helps you write clean code without worrying about slowdowns.

Self-Check

"What if we added a loop that calls sound() on a list of 1000 animals? How would the time complexity change?"

Practice

(1/5)
1. Which statement best describes an abstract class in Java?
easy
A. It is the same as an interface and cannot have any methods with code.
B. It must have all methods fully implemented and can be instantiated.
C. It can have methods without implementation and cannot be instantiated directly.
D. It is a class that can only contain static methods.

Solution

  1. Step 1: Understand abstract class definition

    An abstract class can have methods without implementation (abstract methods) and cannot create objects directly.
  2. Step 2: Compare with other options

    Concrete classes have full method implementations and can be instantiated. Interfaces differ from abstract classes. Static-only classes are unrelated.
  3. Final Answer:

    It can have methods without implementation and cannot be instantiated directly. -> Option C
  4. Quick Check:

    Abstract class = no direct objects [OK]
Hint: Abstract classes can't create objects directly [OK]
Common Mistakes:
  • Thinking abstract classes can be instantiated
  • Confusing abstract classes with interfaces
  • Assuming all methods must be implemented
2. Which of the following is the correct way to declare an abstract class in Java?
easy
A. abstract class Vehicle {}
B. class abstract Vehicle {}
C. Vehicle abstract class {}
D. class Vehicle abstract {}

Solution

  1. Step 1: Recall Java syntax for abstract classes

    The keyword 'abstract' comes before 'class' followed by the class name.
  2. Step 2: Check each option

    Only 'abstract class Vehicle {}' matches correct syntax. The other options have incorrect keyword order.
  3. Final Answer:

    abstract class Vehicle {} -> Option A
  4. Quick Check:

    abstract keyword before class name [OK]
Hint: Put 'abstract' before 'class' keyword [OK]
Common Mistakes:
  • Placing 'abstract' after 'class'
  • Mixing keyword order
  • Omitting 'abstract' keyword
3. What will be the output of the following Java code?
abstract class Animal {
    abstract void sound();
}

class Dog extends Animal {
    void sound() {
        System.out.println("Bark");
    }
}

public class Test {
    public static void main(String[] args) {
        Animal a = new Dog();
        a.sound();
    }
}
medium
A. Runtime error
B. Animal sound
C. Compilation error
D. Bark

Solution

  1. Step 1: Understand class hierarchy and method overriding

    Animal is abstract with abstract method sound(). Dog extends Animal and implements sound() printing "Bark".
  2. Step 2: Analyze main method execution

    Animal reference points to Dog object. Calling a.sound() runs Dog's sound(), printing "Bark".
  3. Final Answer:

    Bark -> Option D
  4. Quick Check:

    Abstract method overridden = Dog's output [OK]
Hint: Abstract method calls run subclass implementation [OK]
Common Mistakes:
  • Expecting abstract class method to run
  • Thinking abstract class can be instantiated
  • Confusing compile and runtime errors
4. Identify the error in the following code snippet:
abstract class Shape {
    abstract void draw();
}

class Circle extends Shape {
    // No draw() method implemented
}

public class Test {
    public static void main(String[] args) {
        Circle c = new Circle();
        c.draw();
    }
}
medium
A. Circle must implement the abstract method draw() or be declared abstract.
B. Cannot create object of class Circle.
C. Abstract class Shape cannot have abstract methods.
D. No error, code runs fine.

Solution

  1. Step 1: Check subclass implementation of abstract methods

    Circle extends Shape but does not implement abstract method draw().
  2. Step 2: Understand Java rules for abstract methods

    A concrete class must implement all abstract methods or be declared abstract itself. Circle is concrete but missing draw().
  3. Final Answer:

    Circle must implement the abstract method draw() or be declared abstract. -> Option A
  4. Quick Check:

    Concrete subclass must implement all abstract methods [OK]
Hint: Concrete class must implement all abstract methods [OK]
Common Mistakes:
  • Thinking abstract methods can be skipped
  • Assuming abstract class can't have abstract methods
  • Believing object creation is the error
5. You want to design a system where different types of employees calculate their salary differently. Which approach best uses abstract and concrete classes?
hard
A. Create only concrete classes for each employee type without any abstract class.
B. Create an abstract class Employee with an abstract method calculateSalary(), then create concrete subclasses like Manager and Developer implementing it.
C. Use an interface with no methods and concrete classes implementing it.
D. Create a concrete Employee class with a fixed calculateSalary() method used by all employees.

Solution

  1. Step 1: Identify need for shared rules with different implementations

    Employee types share concept of salary calculation but differ in details.
  2. Step 2: Use abstract class with abstract method

    Abstract class Employee defines calculateSalary() abstractly. Subclasses implement specific logic.
  3. Step 3: Evaluate other options

    Create only concrete classes for each employee type without any abstract class. lacks shared abstraction. Use an interface with no methods and concrete classes implementing it. uses interface with no methods, so no contract. Create a concrete Employee class with a fixed calculateSalary() method used by all employees. fixes salary calculation, no variation.
  4. Final Answer:

    Create an abstract class Employee with an abstract method calculateSalary(), then create concrete subclasses like Manager and Developer implementing it. -> Option B
  5. Quick Check:

    Abstract class sets rules, subclasses do work [OK]
Hint: Abstract class for rules, concrete classes for details [OK]
Common Mistakes:
  • Not using abstraction for shared behavior
  • Using concrete class with fixed method only
  • Interfaces without methods don't enforce contracts