java-design-patterns/special-case

title, shortTitle, description, category, language, tag

title	shortTitle	description	category	language	tag
Special Case Pattern in Java: Simplifying Exception Handling with Predefined Cases	Special Case	Explore the Special Case design pattern in Java for handling exceptional cases without cluttering the main code logic. Learn its applicability, real-world examples, and benefits for clean, maintainable code.	Structural	en	Abstraction Code simplification Decoupling Error handling Polymorphism Runtime

Also known as

• Exceptional Case

Intent of Special Case Design Pattern

The Special Case design pattern in Java offers a robust framework for addressing unique or exceptional conditions in software development without complicating the main codebase.

Detailed Explanation of Special Case Pattern with Real-World Examples

Real-world example

Consider a toll booth system on a highway. Normally, vehicles pass through the booth, and the system charges a toll based on the vehicle type. However, there are special cases: emergency vehicles like ambulances and fire trucks, which should not be charged.

For instance, in a toll management system, the Special Case pattern facilitates separate handling for emergency vehicles, ensuring a streamlined toll process without additional checks. The emergency vehicle class would override the toll calculation method to ensure no charge is applied, encapsulating this special behavior without cluttering the main toll calculation logic with conditional checks. This keeps the codebase clean and ensures the special case is handled consistently.

In plain words

The Special Case design pattern encapsulates and isolates exceptional conditions and specific scenarios to simplify the main code logic and enhance maintainability.

In Patterns of Enterprise Application Architecture Martin Fowler says:

If you’ll pardon the unresistable pun, I see Null Object as special case of Special Case.

Programmatic Example of Special Case Pattern in Java

The Special Case Pattern is a software design pattern that is used to handle a specific, often uncommon, case separately from the general case in the code. This pattern is useful when a class has behavior that requires conditional logic based on its state. Instead of cluttering the class with conditional logic, we can encapsulate the special behavior in a subclass.

In an e-commerce system, the presentation layer relies on the application layer to generate a specific view model. There is a successful scenario where the receipt view model includes actual purchase data, along with a few failure scenarios.

The Db class is a singleton that holds data for users, accounts, and products. It provides methods to seed data into the database and find data in the database.

@RequiredArgsConstructor
@Getter
public class Db {
    // Singleton instance of Db
    private static Db instance;

    // Maps to hold data
    private Map<String, User> userName2User;
    private Map<User, Account> user2Account;
    private Map<String, Product> itemName2Product;

    // Singleton method to get instance of Db
    public static synchronized Db getInstance() {
        if (instance == null) {
            Db newInstance = new Db();
            newInstance.userName2User = new HashMap<>();
            newInstance.user2Account = new HashMap<>();
            newInstance.itemName2Product = new HashMap<>();
            instance = newInstance;
        }
        return instance;
    }

    // Methods to seed data into Db
    public void seedUser(String userName, Double amount) { /*...*/ }

    public void seedItem(String itemName, Double price) { /*...*/ }

    // Methods to find data in Db
    public User findUserByUserName(String userName) { /*...*/ }

    public Account findAccountByUser(User user) { /*...*/ }

    public Product findProductByItemName(String itemName) { /*...*/ }
}

Next, here are the presentation layer, the receipt view model interface and its implementation of successful scenario.

public interface ReceiptViewModel {
    void show();
}

@RequiredArgsConstructor
@Getter
public class ReceiptDto implements ReceiptViewModel {
    private static final Logger LOGGER = LoggerFactory.getLogger(ReceiptDto.class);

    private final Double price;

    @Override
    public void show() {
        LOGGER.info(String.format("Receipt: %s paid", price));
    }
}

And here are the implementations of failure scenarios, which are the special cases.

public class DownForMaintenance implements ReceiptViewModel {
    private static final Logger LOGGER = LoggerFactory.getLogger(DownForMaintenance.class);

    @Override
    public void show() {
        LOGGER.info("Down for maintenance");
    }
}

public class InvalidUser implements ReceiptViewModel {
    private static final Logger LOGGER = LoggerFactory.getLogger(InvalidUser.class);

    private final String userName;

    public InvalidUser(String userName) {
        this.userName = userName;
    }

    @Override
    public void show() {
        LOGGER.info("Invalid user: " + userName);
    }
}

public class OutOfStock implements ReceiptViewModel {

    private static final Logger LOGGER = LoggerFactory.getLogger(OutOfStock.class);

    private String userName;
    private String itemName;

    public OutOfStock(String userName, String itemName) {
        this.userName = userName;
        this.itemName = itemName;
    }

    @Override
    public void show() {
        LOGGER.info("Out of stock: " + itemName + " for user = " + userName + " to buy");
    }
}

public class InsufficientFunds implements ReceiptViewModel {
    private static final Logger LOGGER = LoggerFactory.getLogger(InsufficientFunds.class);

    private String userName;
    private Double amount;
    private String itemName;

    public InsufficientFunds(String userName, Double amount, String itemName) {
        this.userName = userName;
        this.amount = amount;
        this.itemName = itemName;
    }

    @Override
    public void show() {
        LOGGER.info("Insufficient funds: " + amount + " of user: " + userName
                + " for buying item: " + itemName);
    }
}

Here is the App and its main function that executes the different scenarios.

public class App {

    private static final Logger LOGGER = LoggerFactory.getLogger(App.class);

    private static final String LOGGER_STRING = "[REQUEST] User: {} buy product: {}";
    private static final String TEST_USER_1 = "ignite1771";
    private static final String TEST_USER_2 = "abc123";
    private static final String ITEM_TV = "tv";
    private static final String ITEM_CAR = "car";
    private static final String ITEM_COMPUTER = "computer";

    public static void main(String[] args) {
        // DB seeding
        LOGGER.info("Db seeding: " + "1 user: {\"ignite1771\", amount = 1000.0}, "
                + "2 products: {\"computer\": price = 800.0, \"car\": price = 20000.0}");
        Db.getInstance().seedUser(TEST_USER_1, 1000.0);
        Db.getInstance().seedItem(ITEM_COMPUTER, 800.0);
        Db.getInstance().seedItem(ITEM_CAR, 20000.0);

        final var applicationServices = new ApplicationServicesImpl();
        ReceiptViewModel receipt;

        LOGGER.info(LOGGER_STRING, TEST_USER_2, ITEM_TV);
        receipt = applicationServices.loggedInUserPurchase(TEST_USER_2, ITEM_TV);
        receipt.show();
        MaintenanceLock.getInstance().setLock(false);
        LOGGER.info(LOGGER_STRING, TEST_USER_2, ITEM_TV);
        receipt = applicationServices.loggedInUserPurchase(TEST_USER_2, ITEM_TV);
        receipt.show();
        LOGGER.info(LOGGER_STRING, TEST_USER_1, ITEM_TV);
        receipt = applicationServices.loggedInUserPurchase(TEST_USER_1, ITEM_TV);
        receipt.show();
        LOGGER.info(LOGGER_STRING, TEST_USER_1, ITEM_CAR);
        receipt = applicationServices.loggedInUserPurchase(TEST_USER_1, ITEM_CAR);
        receipt.show();
        LOGGER.info(LOGGER_STRING, TEST_USER_1, ITEM_COMPUTER);
        receipt = applicationServices.loggedInUserPurchase(TEST_USER_1, ITEM_COMPUTER);
        receipt.show();
    }
}

Here is the output from running the example.

11:23:48.669 [main] INFO com.iluwatar.specialcase.App -- Db seeding: 1 user: {"ignite1771", amount = 1000.0}, 2 products: {"computer": price = 800.0, "car": price = 20000.0}
11:23:48.672 [main] INFO com.iluwatar.specialcase.App -- [REQUEST] User: abc123 buy product: tv
11:23:48.672 [main] INFO com.iluwatar.specialcase.DownForMaintenance -- Down for maintenance
11:23:48.672 [main] INFO com.iluwatar.specialcase.MaintenanceLock -- Maintenance lock is set to: false
11:23:48.672 [main] INFO com.iluwatar.specialcase.App -- [REQUEST] User: abc123 buy product: tv
11:23:48.673 [main] INFO com.iluwatar.specialcase.InvalidUser -- Invalid user: abc123
11:23:48.674 [main] INFO com.iluwatar.specialcase.App -- [REQUEST] User: ignite1771 buy product: tv
11:23:48.674 [main] INFO com.iluwatar.specialcase.OutOfStock -- Out of stock: tv for user = ignite1771 to buy
11:23:48.674 [main] INFO com.iluwatar.specialcase.App -- [REQUEST] User: ignite1771 buy product: car
11:23:48.676 [main] INFO com.iluwatar.specialcase.InsufficientFunds -- Insufficient funds: 1000.0 of user: ignite1771 for buying item: car
11:23:48.676 [main] INFO com.iluwatar.specialcase.App -- [REQUEST] User: ignite1771 buy product: computer
11:23:48.676 [main] INFO com.iluwatar.specialcase.ReceiptDto -- Receipt: 800.0 paid

In conclusion, the Special Case Pattern helps to keep the code clean and easy to understand by separating the special case from the general case. It also promotes code reuse and makes the code easier to maintain.

When to Use the Special Case Pattern in Java

• Use when you want to encapsulate and handle special cases or error conditions in a manner that avoids conditional logic scattered throughout the main codebase.
• Useful in scenarios where certain operations have known exceptional cases that require different handling.

Real-World Applications of Special Case Pattern in Java

• Implementing null object patterns to avoid null checks.
• Handling specific business rules or validation logic in e-commerce applications.
• Managing different file formats or protocols in data processing applications.

Benefits and Trade-offs of Special Case Pattern

Benefits:

Adopting the Special Case design pattern

• Simplifies the main logic by removing special case handling from the core algorithms.
• Enhances code readability and maintainability by isolating special cases.

Trade-offs:

• May introduce additional classes or interfaces, increasing the number of components in the system.
• Requires careful design to ensure that special cases are correctly encapsulated and do not introduce unexpected behaviors.

Related Java Design Patterns

• Decorator: Can be used to add special case behavior to objects dynamically without modifying their code.
• Null Object: Used to provide a default behavior for null references, which is a specific type of special case.
• Strategy: Allows dynamic switching of special case behaviors by encapsulating them in different strategy classes.

References and Credits

• Design Patterns: Elements of Reusable Object-Oriented Software
• Effective Java
• Patterns of Enterprise Application Architecture
• Special Case (Martin Fowler)