educative.io

Why are we using enums instead of abstract classes

Courses
,
#1

enum PaymentStatus {
COMPLETED,
FAILED,
PENDING,
UNPAID,
REFUNDED
}

Course: Grokking the Low Level Design Interview Using OOD Principles - Learn Interactively
Lesson: Code for the Parking Lot - Grokking the Low Level Design Interview Using OOD Principles

#2

oh, i got it blc PaymentStatus enum in our parking lot design as it won’t require further modifications. BUT, could you show me, how to use abstract classes instead of enums in this example. thanks

Course: Grokking the Low Level Design Interview Using OOD Principles - Learn Interactively
Lesson: Code for the Parking Lot - Grokking the Low Level Design Interview Using OOD Principles

#3

Query: Why are we using enums instead of abstract classes for PaymentStatus?

Hi @Mohammed_Islam

I hope everything is going well with you. Thank you for reaching out about this.

Enums are used over abstract classes for PaymentStatus in our parking lot design because they are well-suited for representing a fixed set of constant values. Enumerations, such as COMPLETED, FAILED, PENDING, UNPAID, and REFUNDED, are predefined and unlikely to change during the program’s execution. Enums provide a clear and concise way to express such fixed values without creating instances of classes. Additionally, enums offer better type safety and can be easily extended.

I hope that this guide is helpful. Remember that I am always available via message to help you with any difficulty you might encounter.
Happy Learning :slight_smile:

#4

Query: oh, i got it blc PaymentStatus enum in our parking lot design as it won’t require further modifications. BUT, could you show me, how to use abstract classes instead of enums in this example. thanks

Hi @Mohammed_Islam

Certainly! We can achieve a similar representation using abstract classes. In the refactored code, the abstract class PaymentStatus serves as the base class, and concrete classes like CompletedStatus and FailedStatus represent individual payment statuses. This approach allows for greater flexibility in adding methods and behavior associated with each payment status.

Here’s an example of the refactored code:

// Abstract class representing PaymentStatus
abstract class PaymentStatus {
    public abstract void displayStatus(); // Abstract method

    // Static instances representing different payment statuses
    public static final PaymentStatus COMPLETED = new CompletedStatus();
    public static final PaymentStatus FAILED = new FailedStatus();
    public static final PaymentStatus PENDING = new PendingStatus();
    public static final PaymentStatus UNPAID = new UnpaidStatus();
    public static final PaymentStatus REFUNDED = new RefundedStatus();
}

// Concrete implementations of PaymentStatus
class CompletedStatus extends PaymentStatus {
    public void displayStatus() {
        // Implementation for displaying COMPLETED status
        System.out.println("Payment status: COMPLETED");
    }
}

class FailedStatus extends PaymentStatus {
    public void displayStatus() {
        // Implementation for displaying FAILED status
        System.out.println("Payment status: FAILED");
    }
}

class PendingStatus extends PaymentStatus {
    public void displayStatus() {
        // Implementation for displaying PENDING status
        System.out.println("Payment status: PENDING");
    }
}

class UnpaidStatus extends PaymentStatus {
    public void displayStatus() {
        // Implementation for displaying UNPAID status
        System.out.println("Payment status: UNPAID");
    }
}

class RefundedStatus extends PaymentStatus {
    public void displayStatus() {
        // Implementation for displaying REFUNDED status
        System.out.println("Payment status: REFUNDED");
    }
}

// Example usage:
public class PaymentStatusExample {
    public static void main(String[] args) {
        PaymentStatus.COMPLETED.displayStatus();
        PaymentStatus.FAILED.displayStatus();
        PaymentStatus.PENDING.displayStatus();
        PaymentStatus.UNPAID.displayStatus();
        PaymentStatus.REFUNDED.displayStatus();
    }
}

In this refactored example, each payment status is represented by a concrete class extending the abstract PaymentStatus class, providing a framework for additional methods and behavior if needed.

Feel free to reach out if you have any questions or need further assistance. I’m here to help!
Happy Learning :slight_smile: