SOLID Principles in Object-Oriented Design

Vocabulary flashcards covering the key terms and principles presented in the lecture on SOLID object-oriented design.

Structured Programming

A programming paradigm that emphasises linear control flow and discourages the use of unconditional jumps (gotos considered harmful).

Object-Oriented Programming (OOP)

A programming paradigm based on encapsulating data and behaviour inside interacting objects.

Object-Oriented Design (OOD)

The planning phase of OOP focused on organising classes, responsibilities and interactions to produce software that is easy to modify, extend and maintain.

Robert C. Martin ("Uncle Bob")

Author of “Clean Code” and promoter of the SOLID principles for agile, maintainable software.

SOLID

A mnemonic for five design principles—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation and Dependency Inversion—that guide dependency management and maintainability.

Single Responsibility Principle (SRP)

States that a class should have only one reason to change, promoting high cohesion within the class.

Cohesion

The degree to which the responsibilities of a module or class are functionally related.

Book / BookPrinter Example

Illustrates SRP by separating text-related behaviour (Book) from output formatting responsibilities (BookPrinter).

Open/Closed Principle (OCP)

Classes should be open for extension but closed for modification, favouring new behaviour through inheritance or composition over altering existing code.

Private Instance Variables Heuristic

Supporting rule for OCP: keep instance variables private to avoid forcing changes in dependent code.

Liskov Substitution Principle (LSP)

Subtypes must be substitutable for their base types without altering the correctness of the program.

Car / ElectricCar Violation

Demonstrates LSP failure when an ElectricCar cannot implement turnOnEngine(), revealing a wrong abstraction.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods they do not use; prefer several specific interfaces to one "fat" interface.

BearKeeper Example

Shows ISP by splitting a broad BearKeeper interface into BearCleaner, BearFeeder and BearPetter to reduce unnecessary coupling.

Fat Interface

An interface that exposes methods irrelevant to some of its clients, leading to unwanted dependencies.

Dependency Inversion Principle (DIP)

High-level and low-level modules should depend on abstractions, not on concrete classes, enabling decoupled and reusable components.

Abstraction

A stable interface (e.g., an abstract class or interface) that both high-level and low-level components depend on under DIP.

High-Level Component

Module that embodies business rules or policy; should not rely directly on concrete utility or infrastructure classes.

Low-Level Component

Module providing implementation details such as I/O or frameworks; under DIP it depends on abstractions rather than dictating them.

Decoupling

Reducing direct dependencies between modules, improving reuse and maintainability—central goal of DIP and SOLID overall.