Justifications
Justifications
I’ve used this pattern for updating order status, tracking and feedback systems. Using Observer
Pattern is useful and efficient in scenario’s like an object want’s to notify a list of observers of
the state changes. Here in my implementation, it makes sure that the changes in order status
and feedback is correctly communicated with the relevant components where it gives real time
updates and also improves the user’s experience.
Strategy Pattern
I’ve used this pattern to the payment processing where strategy patten have the facility and the
flexibility to switch between different payment methods like credit cards, debit cards and other
wallets. So because of using strategy pattern it is easy to add new payment methods and also
maintain existing payment methods without changing the client code.
Builder Pattern
I’ve used this pattern to implement complex ice cream orders. Because of using this pattern it
simplifies the process of creation of an order where it have several steps like choosing flavours,
toppings, syrups and so on and also because of using Builder Pattern it makes easy to read the
code and also maintain. This facilitates customers to customize and order easily.
State Pattern
I’ve used State Pattern to manage different stages or states of an order like placed, in
preparation and out for delivery. So because of using State Pattern it provides a good and clear
structure for changing through different states in an order, it makes the code more robust
because it makes sures that the state-related things are encapsulated within state objects.
Command Pattern
I’ve used this pattern to represent the actions of the user such as placing an order, giving
feedback. Command Pattern encapsulates the request of an object so it facilitates users to
parameterize clients from different requests, queue or log requests and also it supports to
operations that cannot be done.
Decorator Pattern
I’ve used this pattern to allows for additional features to be added to an order at runtime
without changing the classes that are there , enhancing flexibility and maintainability.
Observer Pattern
interface OrderStatusObserver {
interface FeedbackObserver {
interface OrderTrackingObserver {
@Override
}
class FeedbackSystem implements FeedbackObserver {
@Override
@Override
// Observer Lists
@Override
@Override
@Override
@Override
public void notifyOrderStatus(String status) { /* ... */ }
@Override
@Override
Strategy Pattern
interface PaymentStrategy {
@Override
loyaltyProgram.earnPoints(amount);
@Override
this.paymentStrategy = paymentStrategy;
}
@Override
paymentStrategy.processPayment(amount);
Builder Pattern
class BasicIceCream {
}
Chain of Responsibility Pattern
abstract class CustomizationHandler {
this.nextHandler = nextHandler;
State Pattern
interface OrderState {
@Override
public void prepareOrder(IceCream iceCream) {
System.out.println("Preparing the order.");
}
@Override
public void deliverOrder(IceCream iceCream) {
System.out.println("Cannot deliver, order not prepared.");
}
}
@Override
public void prepareOrder(IceCream iceCream) {
System.out.println("Order in preparation.");
}
@Override
public void deliverOrder(IceCream iceCream) {
System.out.println("Cannot deliver, order not prepared.");
}
}
@Override
public void prepareOrder(IceCream iceCream) {
System.out.println("Order already prepared.");
}
@Override
public void deliverOrder(IceCream iceCream) {
System.out.println("Delivering the order.");
}
}