Java design pattern - How to apply offers on product and shopping cart

Question

I am working on a shopping cart application which will output price of cart. I have 3 classes for this Cart, Purchase, Product

public class Product {

    private int id;
    private String name;
    private double price;
    Offer offer;
// getter setter

    public double getPrice(int quantity) {
        return offer.getPrice....
    }

}

public class Purchase {

    Product product;
    int quantity;
// getter setter

    public double getPrice() {
        return product.getPrice(quantity);
    }

}

public class Cart {

    List<Purchase> purchase = new ArrayList<Purchase>();
    Offer offer;
    Integer loyalityPoints;
//getter setter

    public double getTotal(){
        double total = 0;
        for (Purchase purchase : purchase) {
            total += purchase.getPrice();
        }

        double finalPrice = offer.getPrice(total,....;
        return finalPrice;
    }


}

As shown above individual product can have offer and cart can also have offer.

Initially I thought of having offer factory. OfferPrice can be abstract class & its child could be buyonegetoneprice, buytwogetoneprice, 50precentoffprice but then input for buyonegetoneprice will be qunatity and price and input for 50precentoffprice is only price.

This means 2 different method but implementor of OfferPrice is concerned with only one implementation.

Also how could offer on cart look like? offer on cart can be based on customer loyalityPoints or 50percentoff or something else.

How to design these offers for cart and individual product in a way that could be extensible?

Answer 1

From your example you may need different Offer strategy. In my opinion the You should have all these three classes loosely coupled by using interfaces. Create OfferStrategy and subclasses like Product based offer, Price based offer etc.

This also looks like something that can benefit from Rules engine (You can dynamically change Offer for entire application without stopping the application)

Here is my suggestion for the design (Interfaces for each class, strategy to encapsulate different Offer algorithms which internally use Rules): *Ixxx represents interface, <- represents is a relation

IOffer <- Offer , IProduct <- Product , IPurchase <- Purchase , IOfferStragegy <- OfferStrategy* (Different implementations with common interface method) ICart <- Cart Cart has products and offers.

Here are the benefits/reason for doing this :

1. Assuming that the Offer and Offer implementation are going to keep changing thus needs Interfaces and ability to change at run time.
2. Cart price is determined based on offer strategy

Answer 2

The question is a little bit generic, but i will try to give you some ideas.

1) if you are not already doing it, use TDD, this will help you to improve your design, because if the code is not testable you are doing something bad or sloppy.

2) Use DI ( Dependency Injection ) for almost everything, avoiding the new keyword.

3) Do not try to predict the future, we as humans are really bad at predicting the changes, so, let duplication stay there until it's obvious that something needs a refactoring.

4) Do not apply Design Patterns before they are really required, the reason is the same as point 3

5) Use Interfaces, composition and delegation over inheritance, always.