Object-Oriented Design

Master the principles of Object-Oriented Design (OOD) to build robust, scalable, and maintainable software systems.

What You'll Learn

• Core OOD Concepts: Encapsulation, Abstraction, Inheritance, Polymorphism

• SOLID Principles: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion

• Design Patterns: Creational, Structural, and Behavioral patterns

• UML Diagrams: Visualize system architecture and class relationships

• Clean Code Practices: Write readable, testable, and maintainable code

Preview Chapter: SOLID Principles

The SOLID principles are a set of five design principles intended to make software designs more understandable, flexible, and maintainable.

1. Single Responsibility Principle (SRP)

Definition: A class should have only one reason to change, meaning it should have a single, well-defined responsibility.

Incorrect Example:

classDiagram
    class Employee {
        - String name
        - double salary
        + calculateSalary()
        + generatePayrollReport()
    }

Issue: The Employee class handles both salary calculation and report generation, violating SRP.

Correct Example:

classDiagram
    class Employee {
        - String name
        - double salary
        + calculateSalary()
    }
    class PayrollReportGenerator {
        + generatePayrollReport(Employee employee)
    }
    Employee --o PayrollReportGenerator : uses

Solution: Separate concerns into Employee and PayrollReportGenerator classes.

2. Open/Closed Principle (OCP)

Definition: Software entities (e.g., classes, modules) should be open for extension but closed for modification.

Incorrect Example:

classDiagram
    class AreaCalculator {
        + calculateRectangleArea(Rectangle r)
        + calculateCircleArea(Circle c)
    }
    class Rectangle {
        - int width
        - int height
    }
    class Circle {
        - int radius
    }
    AreaCalculator ..> Rectangle : depends
    AreaCalculator ..> Circle : depends

Issue: Adding a new shape requires modifying AreaCalculator.

Correct Example:

classDiagram
    class Shape {
        <<abstract>>
        + abstract calculateArea()
    }
    class Rectangle {
        - int width
        - int height
        + calculateArea()
    }
    class Circle {
        - int radius
        + calculateArea()
    }
    Shape <|-- Rectangle
    Shape <|-- Circle

Solution: Use an abstract Shape class and extend it for new shapes.

3. Liskov Substitution Principle (LSP)

Definition: Subtypes (derived classes) must be substitutable for their base types (parent classes) without altering the correctness of the program.

Incorrect Example:

classDiagram
    class Bird {
        + fly()
    }
    class Ostrich {
        + fly()
    }
    Bird <|-- Ostrich

Issue: An Ostrich cannot fly, so substituting Ostrich for Bird breaks the fly() contract.

Correct Example:

classDiagram
    class Bird {
        + move()
    }
    class FlyingBird {
        + fly()
    }
    class Ostrich {
        + move()
    }
    Bird <|-- FlyingBird
    Bird <|-- Ostrich
    FlyingBird <|-- Eagle

Solution: Create a FlyingBird subtype for birds that can fly.

4. Interface Segregation Principle (ISP)

Definition: Clients should not be forced to depend on interfaces they don't use.

Incorrect Example:

classDiagram
    interface Worker {
        + work()
        + eat()
        + sleep()
    }
    class HumanWorker {
        + work()
        + eat()
        + sleep()
    }
    class RobotWorker {
        + work()
        + eat()
        + sleep()
    }
    Worker <|.. HumanWorker
    Worker <|.. RobotWorker

Issue: RobotWorker is forced to implement eat() and sleep().

Correct Example:

classDiagram
    interface Workable {
        + work()
    }
    interface Eatable {
        + eat()
    }
    interface Sleepable {
        + sleep()
    }
    class HumanWorker {
        + work()
        + eat()
        + sleep()
    }
    class RobotWorker {
        + work()
    }
    Workable <|.. HumanWorker
    Eatable <|.. HumanWorker
    Sleepable <|.. HumanWorker
    Workable <|.. RobotWorker

Solution: Break down the Worker interface into smaller, role-specific interfaces.

5. Dependency Inversion Principle (DIP)

Definition: High-level modules should not depend on low-level modules; both should depend on abstractions.

Incorrect Example:

classDiagram
    class LightBulb {
        + turnOn()
        + turnOff()
    }
    class Switch {
        - LightBulb bulb
        + operate()
    }
    Switch ..> LightBulb : depends

Issue: Switch (high-level) directly depends on LightBulb (low-level concrete).

Correct Example:

classDiagram
    interface SwitchableDevice {
        + turnOn()
        + turnOff()
    }
    class LightBulb {
        + turnOn()
        + turnOff()
    }
    class Switch {
        - SwitchableDevice device
        + operate()
    }
    SwitchableDevice <|.. LightBulb
    Switch ..> SwitchableDevice : depends

Solution: Introduce SwitchableDevice interface, making Switch depend on the abstraction.

Course Structure

1. Introduction to OOD (30 minutes)

- What is OOP?

- Why OOD matters

- Core principles: Encapsulation, Abstraction, Inheritance, Polymorphism

2. Mastering SOLID Principles (1.5 hours)

- Deep dive into each of the 5 principles with examples

- Identifying violations and refactoring

- Practical application in real-world scenarios

3. Common Design Patterns (1 hour)

- Creational: Singleton, Factory, Abstract Factory, Builder, Prototype

- Structural: Adapter, Decorator, Facade, Proxy

- Behavioral: Observer, Strategy, Command, Iterator

4. UML Diagrams for OOD (30 minutes)

- Class diagrams

- Sequence diagrams

- Component diagrams

- Best practices for modeling

5. Case Studies & Practice (1 hour)

- Design a Parking Lot system

- Design a Library Management system

- Design a Vending Machine

- Code reviews and refactoring exercises

What's Next

After mastering Object-Oriented Design, you'll be able to write code that is not only functional but also highly maintainable, scalable, and easy to extend. You'll have a strong foundation for tackling complex software engineering challenges and contributing to large codebases with confidence.