OOP Design

classes
objects
responsibilities
relationships
dependencies
interfaces
data
behavior

class ShoppingApp {
    // 3000 lines
}

understand
test
modify
debug
reuse
extend

syntax
types
method calls
access rules

"This class has too many responsibilities."

"This design is tightly coupled."

"You should use composition."

"This class is difficult to test."

"This interface is badly designed."

easy to understand
easy to change
easy to test
easy to extend
easy to reuse
harder to break accidentally

UPI

Credit Card

Wallet

class OrderService {

    void process() {

        // calculate price
        // validate customer
        // save order
        // send email
        // process payment
        // generate invoice
    }
}

OrderValidator
OrderCalculator
OrderRepository
PaymentService
EmailService
InvoiceGenerator

class Invoice {

    double calculateTotal() {
        // invoice calculation
    }
}

class Invoice {

    double calculateTotal() {
    }

    void sendEmail() {
    }

    void saveToDatabase() {
    }

    void connectToPaymentGateway() {
    }
}

S — Single Responsibility Principle

A class must contain exactly one method.

class Invoice {

    void calculateTotal() {
    }

    void saveToDatabase() {
    }

    void sendEmail() {
    }
}

pricing rules change
database logic changes
email requirements change

class Invoice {

    double calculateTotal() {
        return 0;
    }
}

class InvoiceRepository {

    void save(Invoice invoice) {
    }
}

class InvoiceEmailService {

    void send(Invoice invoice) {
    }
}

Invoice
→ invoice behavior

InvoiceRepository
→ persistence

InvoiceEmailService
→ email

AddService
SubtractService
MultiplyService
DivisionService

meaningful responsibility boundaries

class BankAccount {

    deposit()
    withdraw()
    getBalance()
}

class Utility {

    sendEmail()
    calculateTax()
    resizeImage()
    saveDatabase()
    printReport()
}

class ShoppingCart {

    addItem()
    removeItem()
    calculateTotal()
    clear()
}

class OrderService {

    private final StripePayment payment;

    OrderService() {
        payment =
            new StripePayment();
    }
}

interface Payment {

    void pay(double amount);
}

class OrderService {

    private final Payment payment;

    OrderService(Payment payment) {
        this.payment = payment;
    }
}

Coupling
→ relationship BETWEEN classes

Cohesion
→ relationship WITHIN a class

LOW unnecessary coupling
HIGH cohesion

OrderService → Payment

OrderService → Payment
                    ↑
             ┌──────┴──────┐
             │             │
        CardPayment    UpiPayment

CardPayment payment;

Payment payment;

interface Payment {

    void pay(double amount);
}

class Checkout {

    private final Payment payment;

    Checkout(Payment payment) {
        this.payment = payment;
    }
}

"I need something that can make a payment."

"I specifically need this exact payment class."

class Checkout {

    private final Payment payment;

    Checkout(Payment payment) {
        this.payment = payment;
    }
}

testability
replaceability
flexibility
separation of concerns

Checkout real =
    new Checkout(
        new CardPayment()
    );

Checkout test =
    new Checkout(
        new FakePayment()
    );

O — Open/Closed Principle

Add new behavior
without repeatedly changing stable existing code.

interface Payment {

    void pay(double amount);
}

class CardPayment
        implements Payment {

    public void pay(double amount) {
        System.out.println(
            "Card payment"
        );
    }
}

class UpiPayment
        implements Payment {

    public void pay(double amount) {
        System.out.println(
            "UPI payment"
        );
    }
}

class WalletPayment
        implements Payment {

    public void pay(double amount) {
        System.out.println(
            "Wallet payment"
        );
    }
}

"Existing code can never be edited."

L — Liskov Substitution Principle

class Bird {

    void eat() {
        System.out.println(
            "Eating"
        );
    }
}

class Sparrow
        extends Bird {

    void fly() {
        System.out.println(
            "Flying"
        );
    }
}

Bird bird =
    new Sparrow();

bird.eat();

setWidth()
setHeight()

"This thing is technically a type of that thing."

Can the child safely replace the parent?

class Bird {

    void move() {
        System.out.println(
            "Moving"
        );
    }
}

"move performs a valid movement"

I — Interface Segregation Principle

Prefer small, focused interfaces
over one huge interface.

interface Machine {

    void print();

    void scan();

    void fax();
}

scan()
fax()

interface Printable {

    void print();
}

interface Scannable {

    void scan();
}

interface Faxable {

    void fax();
}

class MultiFunctionPrinter
        implements
        Printable,
        Scannable,
        Faxable {

    public void print() {
    }

    public void scan() {
    }

    public void fax() {
    }
}

class SimplePrinter
        implements Printable {

    public void print() {
    }
}

D — Dependency Inversion Principle

class OrderService {

    private final MySQLDatabase db =
        new MySQLDatabase();
}

interface OrderRepository {

    void save(Order order);
}

class MySQLOrderRepository
        implements OrderRepository {

    public void save(Order order) {
        System.out.println(
            "Saving to MySQL"
        );
    }
}

class OrderService {

    private final OrderRepository repository;

    OrderService(
        OrderRepository repository
    ) {
        this.repository = repository;
    }
}

S → Single Responsibility
    One focused reason to change

O → Open/Closed
    Extend behavior without unnecessary modification

L → Liskov Substitution
    Subtypes should preserve parent expectations

I → Interface Segregation
    Prefer focused interfaces

D → Dependency Inversion
    Depend on abstractions, not concrete details

solid

classes
interfaces
abstract classes
inheritance
composition
polymorphism
access modifiers
dependency injection

Car
Engine

class Car extends Engine {
}

class Car {

    private final Engine engine;

    Car(Engine engine) {
        this.engine = engine;
    }
}

hard-to-follow behavior
fragile parent-child dependencies
unexpected inherited behavior
difficult changes

String

final class Person {

    private final String name;
    private final int age;

    Person(
        String name,
        int age
    ) {
        this.name = name;
        this.age = age;
    }

    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }
}

1. Prevent unintended subclass mutation.
2. Keep state private.
3. Make fields final where appropriate.
4. Initialize state during construction.
5. Do not provide mutating methods.
6. Defensively copy mutable input/output.

safer sharing
simpler reasoning
fewer accidental state changes
easier testing
better suitability for concurrent use

private final List<String> names;

names.add("Aman");

final reference
≠
immutable object

class Student {

    private final List<String> subjects;

    Student(List<String> subjects) {
        this.subjects = subjects;
    }
}

this.subjects =
    new ArrayList<>(subjects);

List<String> getSubjects() {
    return subjects;
}

return List.copyOf(subjects);

return Collections.unmodifiableList(subjects);

return List.copyOf(subjects);

return Collections.unmodifiableList(subjects);

Money
EmailAddress
Coordinate
DateRange
Address

final class Money {

    private final int amount;
    private final String currency;

    Money(
        int amount,
        String currency
    ) {
        this.amount = amount;
        this.currency = currency;
    }

    int getAmount() {
        return amount;
    }

    String getCurrency() {
        return currency;
    }
}

Money(100, "INR")

Money(100, "INR")

Employee ID = 101

Money = ₹500

different identities
same value

fields
+
getters
+
setters

class BankAccount {

    private double balance;

    void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Amount must be positive"
            );
        }

        balance += amount;
    }

    void withdraw(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Amount must be positive"
            );
        }

        if (amount > balance) {
            throw new IllegalArgumentException(
                "Insufficient balance"
            );
        }

        balance -= amount;
    }

    double getBalance() {
        return balance;
    }
}

private fields
+
getters
+
setters

class BankAccount {

    private double balance;

    double getBalance() {
        return balance;
    }

    void setBalance(double balance) {
        this.balance = balance;
    }
}

account.setBalance(
    account.getBalance() - amount
);

account.setBalance(-5000);

account.withdraw(5000);

if (account.getBalance() >= amount) {
    account.setBalance(
        account.getBalance() - amount
    );
}

account.withdraw(amount);

Service knows Account internals

Service asks Account to withdraw
Account enforces Account rules

order.getCustomer()
     .getAddress()
     .getCity()
     .getName();

Order
 → Customer
 → Address
 → City

order.getShippingCity();

class ApplicationManager {

    // users
    // payments
    // database
    // email
    // reports
    // authentication
    // logging
    // file handling
    // UI
    // configuration
}

low cohesion
high coupling
large size
many reasons to change
difficult testing
difficult reuse

class Shop {

    void registerUser() {}
    void loginUser() {}
    void saveUser() {}
    void processPayment() {}
    void sendEmail() {}
    void generateInvoice() {}
}

UserService
AuthenticationService
UserRepository
PaymentService
EmailService
InvoiceService

UserServiceInterface
UserServiceInterfaceImpl

multiple implementations
decoupling
polymorphism
clear contract
testing
architectural boundaries

"Every class must have an interface."

PaymentManagerFactoryProviderAdapter

payment.pay();

Current requirement:
One payment method.

12 interfaces
7 factories
4 abstract factories
3 adapters

Don't Repeat Yourself

double calculateTaxForOrder(...) {
    // tax formula
}

double calculateTaxForInvoice(...) {
    // same tax formula
}

Do they represent the same business rule?
Will they change for the same reason?

Keep It Simple

class Calculator {

    int add(int a, int b) {
        return a + b;
    }
}

God class
deep inheritance
large methods
too many parameters
too many responsibilities
tight coupling
low cohesion
duplicate logic
excessive getters/setters
public mutable state
unnecessary interfaces
unnecessary abstraction
long method chains

"Look more closely."

createUser(
    String name,
    int age,
    String city,
    String state,
    String country,
    String phone,
    String email
);

Address
ContactInfo
User

createUser(
    String name,
    int age,
    Address address,
    ContactInfo contact
);

class Address {

    private final String city;
    private final String state;
    private final String country;

    Address(
        String city,
        String state,
        String country
    ) {
        this.city = city;
        this.state = state;
        this.country = country;
    }
}

void register(
    String name,
    Address address
) {
}

class User {

    public String name;
}

class User {

    private String name;

    public String getName() {
        return name;
    }

    public void rename(String name) {
        // validation
        this.name = name;
    }
}

balance cannot be negative

age must be valid

total cannot be negative

class Product {

    private final String name;
    private final double price;

    Product(
        String name,
        double price
    ) {

        if (name == null ||
            name.isBlank()) {

            throw new IllegalArgumentException(
                "Invalid name"
            );
        }

        if (price < 0) {

            throw new IllegalArgumentException(
                "Invalid price"
            );
        }

        this.name = name;
        this.price = price;
    }
}

Order order =
    new Order();

order.setStatus("xyz");

order.cancel();
order.ship();
order.deliver();

enum OrderStatus {

    CREATED,
    PAID,
    SHIPPED,
    DELIVERED,
    CANCELLED
}

class Order {

    private OrderStatus status =
        OrderStatus.CREATED;

    void pay() {
        if (status != OrderStatus.CREATED) {
            throw new IllegalStateException(
                "Order cannot be paid now"
            );
        }

        status = OrderStatus.PAID;
    }
}

order.setStatus(OrderStatus.SHIPPED);

order.ship();

what callers need

how the class internally works

account.withdraw(1000);

how balance is stored
how validation works
how transaction records are created

private double balance;

private BigDecimal balance;

deposit()
withdraw()
getBalance()

private final String name;

public String name;

private field
+
getter
+
setter
=
perfect encapsulation

cart.getItems().add(product);

cart.addItem(product);

null checks
duplicates
quantity
inventory rules
pricing
events

class Cart {

    private final List<Product> items =
        new ArrayList<>();

    List<Product> getItems() {
        return items;
    }
}

cart.getItems().clear();

void addItem(Product product) {
    items.add(product);
}

void removeItem(Product product) {
    items.remove(product);
}

List<Product> getItems() {
    return List.copyOf(items);
}

class must be under 100 lines

class must have 5 methods

Is the class understandable?
Does it have a focused responsibility?
Are its methods related?
Is it changing for many unrelated reasons?

does many unrelated tasks
contains deeply nested logic
is hard to test
has many local variables
has many branches

calculateTotal()
withdraw()
cancel()
sendInvoice()

doStuff()
process()
handle()
run()

Book
Member
Loan
Fine

Account
Transaction
Deposit
Withdrawal

createUser(
    "Aman",
    true,
    false,
    true
);

UserOptions options =
    new UserOptions(
        true,
        false,
        true
    );

if (order.getStatus() == PAID) {
    order.setStatus(SHIPPED);
}

order.ship();

design principle

technique for supplying dependencies

Checkout(Payment payment)

Payment

contract
capability
multiple implementations
multiple inheritance of type

shared state
shared implementation
constructor
common protected behavior

class Checkout {

    private final Payment payment;

    Checkout(Payment payment) {
        this.payment = payment;
    }
}

composition
+
abstraction
+
polymorphism
+
dependency injection

class OrderService {

    private final Payment payment;

    OrderService(Payment payment) {
        this.payment = payment;
    }
}

FakePayment

interface Payment {

    void pay(double amount);
}

class FakePayment
        implements Payment {

    double lastAmount;

    @Override
    public void pay(double amount) {
        lastAmount = amount;
    }
}

FakePayment fake =
    new FakePayment();

OrderService service =
    new OrderService(fake);

extract class
extract method
rename method
replace inheritance with composition
introduce interface
move responsibility
encapsulate field
remove duplication

class Order {

    void checkout() {

        // calculate total
        // validate payment
        // save order
        // send email
    }
}

Order
OrderCalculator
PaymentService
OrderRepository
EmailService

1. Understand current behavior.
2. Identify one design problem.
3. Make one small change.
4. Compile/test.
5. Repeat.

class ShoppingApplication {

    private List<Product> products;

    void addProduct(Product product) {
        products.add(product);
    }

    void processPayment(double amount) {
        // payment gateway
    }

    void sendEmail(String message) {
        // email
    }

    void saveDatabase() {
        // database
    }

    void generateReport() {
        // reporting
    }

    void calculateTax() {
        // tax
    }
}

low cohesion
high coupling
many reasons to change
too many responsibilities
hard testing

class ShoppingCart {

    void addProduct(Product product) {
    }

    double calculateTotal() {
        return 0;
    }
}

class PaymentService {

    void pay(double amount) {
    }
}

class EmailService {

    void send(String message) {
    }
}

class ProductRepository {

    void save(Product product) {
    }
}

class BankAccount {

    private final String accountNumber;
    private double balance;

    BankAccount(
        String accountNumber,
        double openingBalance
    ) {

        if (openingBalance < 0) {
            throw new IllegalArgumentException(
                "Opening balance cannot be negative"
            );
        }

        this.accountNumber =
            accountNumber;

        this.balance =
            openingBalance;
    }

    void deposit(double amount) {

        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Amount must be positive"
            );
        }

        balance += amount;
    }

    void withdraw(double amount) {

        if (amount <= 0) {
            throw new IllegalArgumentException(
                "Amount must be positive"
            );
        }

        if (amount > balance) {
            throw new IllegalArgumentException(
                "Insufficient balance"
            );
        }

        balance -= amount;
    }

    double getBalance() {
        return balance;
    }
}

account state
deposit
withdrawal
balance rules

interface Discount {

    double calculate(double amount);
}

class NoDiscount
        implements Discount {

    public double calculate(
        double amount
    ) {
        return 0;
    }
}

class StudentDiscount
        implements Discount {

    public double calculate(
        double amount
    ) {
        return amount * 0.10;
    }
}

class Checkout {

    private final Discount discount;

    Checkout(Discount discount) {
        this.discount = discount;
    }

    double finalPrice(double amount) {

        return amount -
               discount.calculate(amount);
    }
}

interface Printable {

    void print();
}

interface Scannable {

    void scan();
}

class SimplePrinter
        implements Printable {

    @Override
    public void print() {
        System.out.println(
            "Printing"
        );
    }
}

class OfficeMachine
        implements Printable,
        Scannable {

    @Override
    public void print() {
        System.out.println(
            "Printing"
        );
    }

    @Override
    public void scan() {
        System.out.println(
            "Scanning"
        );
    }
}

interface UserRepository {

    void save(String username);
}

class DatabaseUserRepository
        implements UserRepository {

    @Override
    public void save(
        String username
    ) {
        System.out.println(
            "Saving " +
            username +
            " to database"
        );
    }
}

class UserService {

    private final UserRepository repository;

    UserService(
        UserRepository repository
    ) {
        this.repository = repository;
    }

    void register(String username) {
        repository.save(username);
    }
}

public class Main {

    public static void main(
        String[] args
    ) {

        UserRepository repository =
            new DatabaseUserRepository();

        UserService service =
            new UserService(repository);

        service.register("Aman");
    }
}

Saving Aman to database

final class Student {

    private final String name;
    private final int age;

    Student(
        String name,
        int age
    ) {

        if (name == null ||
            name.isBlank()) {

            throw new IllegalArgumentException(
                "Invalid name"
            );
        }

        if (age < 0) {
            throw new IllegalArgumentException(
                "Invalid age"
            );
        }

        this.name = name;
        this.age = age;
    }

    String getName() {
        return name;
    }

    int getAge() {
        return age;
    }
}

name cannot be changed
age cannot be changed

import java.util.ArrayList;
import java.util.List;

final class Student {

    private final List<String> subjects;

    Student(List<String> subjects) {

        this.subjects =
            new ArrayList<>(subjects);
    }

    List<String> getSubjects() {
        return List.copyOf(subjects);
    }
}

enum OrderStatus {

    CREATED,
    PAID,
    SHIPPED,
    CANCELLED
}

class Order {

    private OrderStatus status =
        OrderStatus.CREATED;

    void pay() {

        if (status !=
            OrderStatus.CREATED) {

            throw new IllegalStateException(
                "Cannot pay this order"
            );
        }

        status = OrderStatus.PAID;
    }

    void ship() {

        if (status !=
            OrderStatus.PAID) {

            throw new IllegalStateException(
                "Only paid orders can ship"
            );
        }

        status = OrderStatus.SHIPPED;
    }

    void cancel() {

        if (status ==
            OrderStatus.SHIPPED) {

            throw new IllegalStateException(
                "Shipped order cannot be cancelled"
            );
        }

        status = OrderStatus.CANCELLED;
    }

    OrderStatus getStatus() {
        return status;
    }
}

interface NotificationSender {

    void send(String message);
}

class EmailSender
        implements NotificationSender {

    public void send(
        String message
    ) {
        System.out.println(
            "Email: " + message
        );
    }
}

class SmsSender
        implements NotificationSender {

    public void send(
        String message
    ) {
        System.out.println(
            "SMS: " + message
        );
    }
}

class NotificationService {

    private final NotificationSender sender;

    NotificationService(
        NotificationSender sender
    ) {
        this.sender = sender;
    }

    void notifyUser(String message) {
        sender.send(message);
    }
}

NotificationService email =
    new NotificationService(
        new EmailSender()
    );

NotificationService sms =
    new NotificationService(
        new SmsSender()
    );

class ECommerceApplication {
    // everything
}

class ProductService {
}

class CartService {
}

class OrderService {
}

class PaymentService {
}

class NotificationService {
}

final class User {

    private final String name;

    User(String name) {
        this.name = name;
    }

    String getName() {
        return name;
    }
}

No

List<String> list =
    new ArrayList<>();

final List<String> names =
    list;

names.add("Aman");

System.out.println(names);

[Aman]

interface Engine {

    void start();
}

class PetrolEngine
        implements Engine {

    public void start() {
        System.out.println(
            "Petrol"
        );
    }
}

class Car {

    private final Engine engine;

    Car(Engine engine) {
        this.engine = engine;
    }

    void start() {
        engine.start();
    }
}

new Car(
    new PetrolEngine()
).start();

Petrol

interface Payment {

    void pay();
}

class CardPayment
        implements Payment {

    public void pay() {
        System.out.println("Card");
    }
}

class UpiPayment
        implements Payment {

    public void pay() {
        System.out.println("UPI");
    }
}

Payment payment =
    new UpiPayment();

payment.pay();

UPI

class Account {

    private double balance = 1000;

    void withdraw(double amount) {

        if (amount > balance) {
            throw new IllegalArgumentException();
        }

        balance -= amount;
    }

    double getBalance() {
        return balance;
    }
}

Account account =
    new Account();

account.withdraw(300);

System.out.println(
    account.getBalance()
);

700.0

List<String> original =
    new ArrayList<>();

original.add("Java");

List<String> copy =
    List.copyOf(original);

original.add("Python");

System.out.println(copy);

[Java]

List<String> original =
    new ArrayList<>();

original.add("Java");

List<String> view =
    Collections.unmodifiableList(
        original
    );

original.add("Python");

System.out.println(view);

[Java, Python]

class Invoice {

    void calculateTotal() {
    }

    void sendEmail() {
    }

    void saveDatabase() {
    }
}

No.

Yes.

high cohesion
low unnecessary coupling
clear responsibilities
encapsulation
appropriate abstraction
manageable dependencies

S — Single Responsibility Principle
O — Open/Closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

private state
final fields where appropriate
initialize state in constructor
no mutating setters
defensive copying
final class when subclass mutation must be prevented

class Checkout {

    void payByCard(double amount) {
    }

    void payByUpi(double amount) {
    }

    void payByWallet(double amount) {
    }
}

1. Identify the design problem.
2. Create a Payment interface.
3. Create CardPayment.
4. Create UpiPayment.
5. Create WalletPayment.
6. Make Checkout depend on Payment.

interface SmartDevice {

    void print();
    void scan();
    void fax();
}

SimplePrinter
Scanner
FaxMachine
MultiFunctionMachine

Student

name
rollNumber
subjects

private fields
final fields
constructor validation
defensive copy of subjects
no setters
safe getter for subjects

BankAccount

deposit()
withdraw()
transfer()
getBalance()

balance cannot become negative
amount must be positive
account number cannot change

Order

CREATED
PAID
SHIPPED
DELIVERED
CANCELLED

pay()
ship()
deliver()
cancel()

setStatus(...)

NotificationService
NotificationSender
EmailSender
SmsSender
PushSender

EmailNotificationService extends NotificationService
SmsNotificationService extends NotificationService
PushNotificationService extends NotificationService

UserRepository
MySQLUserRepository
MemoryUserRepository
UserService

class Order {

    void calculateTotal() {}
    void saveToDatabase() {}
    void sendEmail() {}
    void processPayment() {}
}

SRP
coupling
cohesion
dependency injection

registerUser(
    String name,
    String city,
    String state,
    String country,
    String phone,
    String email
)

Address
ContactInfo

if (account.getBalance() >= amount) {
    account.setBalance(
        account.getBalance() - amount
    );
}

account.withdraw(amount);

Payment

CardPayment
UpiPayment

Shape
Circle
Rectangle
Triangle
AreaCalculator

if shape instanceof Circle

calculateSalary()
sendEmail()
saveDatabase()
generateInvoice()
printReport()

Version A:
Service directly creates MySQLRepository

Version B:
Service receives Repository interface

coupling
testing
replacement
maintenance

Customer
Address
Product
Cart
CartItem
Order
Payment
PaymentProcessor
OrderRepository
NotificationSender

1. Customer has Address.
2. Cart contains CartItems.
3. CartItem refers to Product.
4. Order uses Payment.
5. Payment is an interface.
6. NotificationSender is an interface.
7. Repository is an abstraction.
8. Dependencies are injected.
9. Objects protect their own state.
10. Avoid a God class.

Bank
Account
Customer
Transaction
AccountRepository
NotificationService

1. Account controls deposit/withdrawal.
2. Balance cannot be changed directly.
3. Transaction records operations.
4. Repository is an abstraction.
5. Notification is injected.
6. Use immutable value objects where appropriate.
7. Keep classes cohesive.

NotificationService
NotificationSender
EmailSender
SmsSender
PushSender

1. Use an interface.
2. Use composition.
3. Use constructor injection.
4. Support multiple senders.
5. Avoid inheritance for sender selection.
6. Make testing possible using FakeNotificationSender.

Library
Book
Member
Loan
FineCalculator
NotificationSender

1. Library manages books.
2. Member can borrow books.
3. Loan represents the borrowing relationship.
4. FineCalculator calculates fines.
5. NotificationSender is an abstraction.
6. Avoid putting every operation in Library.
7. Protect internal collections.

Order
OrderItem
Payment
PaymentRepository
OrderRepository
NotificationSender
OrderService

interfaces
composition
dependency injection
encapsulation
immutable values
SOLID principles

movement
attack
defense
weapon

if (type.equals("CARD")) {
    // card
} else if (type.equals("UPI")) {
    // UPI
} else if (type.equals("WALLET")) {
    // wallet
}

Payment interface
CardPayment
UpiPayment
WalletPayment

Money

amount
currency

immutable
value equality
validation
add()
subtract()

Money a =
    new Money(100, "INR");

Money b =
    new Money(50, "INR");

Money c =
    a.add(b);

150 INR

Order

CREATED
PAID
SHIPPED
DELIVERED
CANCELLED

CREATED → PAID
PAID → SHIPPED
SHIPPED → DELIVERED
CREATED → CANCELLED
PAID → CANCELLED

class UserManager {

    void createUser() {}
    void deleteUser() {}
    void sendEmail() {}
    void saveToDatabase() {}
    void calculateTax() {}
    void generateInvoice() {}
    void printReport() {}
    void processPayment() {}
}

God class
low cohesion
high coupling
SRP violation
many reasons to change
difficult testing

1. What does this class represent?

2. What is its main responsibility?

3. Does it have unrelated responsibilities?

4. What state should it own?

5. What state should it hide?

6. Which invariants must it protect?

7. What behavior belongs inside it?

8. Which other objects does it need?

9. Can those dependencies be abstractions?

10. Should dependencies be injected?

11. Is inheritance actually a true IS-A relationship?

12. Would composition be more flexible?

13. Is the class highly cohesive?

14. Is coupling unnecessarily high?

15. Is the public API exposing too much?

16. Can invalid states be prevented?

17. Is the object mutable unnecessarily?

18. Do collections need defensive copies?

19. Is an interface actually useful?

20. Am I overengineering?

"What classes do I need?"

"What responsibilities exist?"

Which object should own each responsibility?

How should those objects collaborate?

What should be public?
What should remain private?

What dependencies can change?

I need 20 classes.

What does the system need to do?

Place order
Calculate price
Process payment
Save order
Send confirmation

Order
PricingService
Payment
OrderRepository
NotificationSender

Order → PricingService
OrderService → Payment
OrderService → OrderRepository
OrderService → NotificationSender

association?
dependency?
composition?
interface?

interface Payment

Payment payment =
    new CardPayment();

Payment payment =
    new UpiPayment();

Payment

class WalletPayment
        implements Payment {
}

interfaces
polymorphism
composition
dependency injection
OCP
DIP

Online Store

customers place orders
orders contain products
payment can be Card/UPI
orders are stored
confirmation is sent

interface Payment {

    void pay(double amount);
}

interface OrderRepository {

    void save(Order order);
}

interface NotificationSender {

    void send(String message);
}

class OrderService {

    private final Payment payment;
    private final OrderRepository repository;
    private final NotificationSender sender;

    OrderService(
        Payment payment,
        OrderRepository repository,
        NotificationSender sender
    ) {
        this.payment = payment;
        this.repository = repository;
        this.sender = sender;
    }
}

Payment
OrderRepository
NotificationSender

CardPayment
UpiPayment

MySQLOrderRepository
MemoryOrderRepository

EmailSender
SmsSender

class Calculator {

    int add(int a, int b) {
        return a + b;
    }
}

CalculatorInterface
CalculatorFactory
CalculatorProvider
CalculatorManager
CalculatorAdapter

Change email provider

EmailSender implementation

Order
Customer
Product
Cart
Payment

Order
→ test order rules

Payment
→ test payment behavior

PricingService
→ test pricing rules

OrderRepository
→ test persistence separately

Add a new payment method.

create new Payment implementation

modify 10 unrelated classes

wrong price?
→ PricingService

payment problem?
→ Payment implementation

database problem?
→ Repository

email problem?
→ NotificationSender

everything could be the problem

1. Using inheritance only for code reuse.

2. Making every field public.

3. Creating getters and setters for everything.

4. Creating one giant class.

5. Creating an interface for every class automatically.

6. Using deep inheritance unnecessarily.

7. Putting all business logic into Service classes.

8. Letting outside code manipulate internal collections.

9. Allowing invalid object states.

10. Creating too many abstractions.

11. Copy-pasting business rules.

12. Ignoring coupling.

13. Ignoring cohesion.

14. Making dependencies with concrete implementations unnecessarily.

15. Confusing final references with immutable objects.

16. Treating SOLID as rigid laws instead of design guidelines.

17. Designing for imaginary future requirements.

18. Using patterns just to show knowledge.

19. Overusing static mutable state.

20. Optimizing architecture before understanding the problem.

OrderService

Payment
Repository
Notification

interface Payment {
    void pay(double amount);
}

interface OrderRepository {
    void save(Order order);
}

interface NotificationSender {
    void send(String message);
}

class OrderService {

    private final Payment payment;
    private final OrderRepository repository;
    private final NotificationSender sender;

    OrderService(
        Payment payment,
        OrderRepository repository,
        NotificationSender sender
    ) {
        this.payment = payment;
        this.repository = repository;
        this.sender = sender;
    }
}

SRP
→ OrderService coordinates order processing

OCP
→ new implementations can be added

LSP
→ implementations should honor contracts

ISP
→ focused interfaces

DIP
→ OrderService depends on abstractions

more classes = better
more interfaces = better
more abstraction = better

Use the principle when it improves the design.

small college assignment

5 classes

large production system

interfaces
modules
repositories
services
domain objects
dependency injection

problem
requirements
team
scale
change frequency
testing needs

Is this class responsible for the right thing?

Is this relationship correct?

Is this dependency necessary?

Can this implementation change independently?

Am I exposing too much?

Am I adding unnecessary complexity?

class
object
extends
implements

High cohesion
Low unnecessary coupling
Encapsulation
Clear responsibilities
Programming to abstractions
Composition over inheritance
Dependency injection
Immutability where useful

S → Single Responsibility
O → Open/Closed
L → Liskov Substitution
I → Interface Segregation
D → Dependency Inversion

Tell, Don't Ask
Law of Demeter
DRY
KISS
YAGNI
Defensive copying
Value objects
Behavior-rich objects
Invariant protection
Avoiding God classes
Avoiding overengineering

[ ] What is software design?
[ ] What is good OOP design?
[ ] What is responsibility?
[ ] What is cohesion?
[ ] What is coupling?
[ ] High cohesion vs low cohesion
[ ] High coupling vs low coupling
[ ] Single Responsibility Principle
[ ] Open/Closed Principle
[ ] Liskov Substitution Principle
[ ] Interface Segregation Principle
[ ] Dependency Inversion Principle
[ ] Complete SOLID
[ ] Programming to abstractions
[ ] Dependency Injection
[ ] Composition over inheritance
[ ] Immutable objects
[ ] final vs immutable
[ ] Defensive copying
[ ] Value objects
[ ] Behavior-rich objects
[ ] Anemic object model
[ ] Tell, Don't Ask
[ ] Law of Demeter
[ ] God class
[ ] Overengineering
[ ] YAGNI
[ ] DRY
[ ] KISS
[ ] Invariants
[ ] Encapsulation and API design
[ ] Protecting collections
[ ] Design smells
[ ] Refactoring
[ ] Designing for change
[ ] Designing for testing

Chapter 11
OOP Fundamentals
        ↓
Chapter 12
Classes & Objects
        ↓
Chapter 13
Constructors
        ↓
Chapter 14
this & static
        ↓
Chapter 15
Encapsulation
        ↓
Chapter 16
Inheritance
        ↓
Chapter 17
Method Overloading
        ↓
Chapter 18
Method Overriding
        ↓
Chapter 19
Polymorphism
        ↓
Chapter 20
Abstraction
        ↓
Chapter 21
Interfaces
        ↓
Chapter 22
OOP Relationships
        ↓
Chapter 23
OOP Design

"I know Java OOP syntax."

"I can reason about how Java classes should be designed."

Chapter 24 → Packages & Access Modifiers
Chapter 25 → Exception Handling
Chapter 26 → File Handling
Chapter 27 → Wrapper Classes
Chapter 28 → Generics
Chapter 29 → Enums
Chapter 30 → Date & Time
Chapter 31 → Collections
...