SOLID Principles: A Complete Deep Dive

Prerequisite: Working familiarity with Python object-oriented programming, specifically classes, objects, inheritance, method overriding, polymorphism, and abstract base classes. If any of those terms are unfamiliar, study the OOP document first, because every argument in this document is expressed in that vocabulary.

What this document delivers: A rigorous treatment of the five SOLID principles. For each principle you will find its formal statement, a precise interpretation of every term in that statement, the concrete engineering problem it solves, a worked example of the problem and its resolution, the alternative techniques available for the same goal, the costs of applying the principle, and the conditions under which it should not be applied.

How to read it: Sequentially. Section 4 defines the vocabulary used throughout. Sections 5 to 9 develop the principles one at a time, each building on terms established earlier. Section 10 explains how the five interact as a system, and Section 11 applies all five to a single realistic codebase.

Table of Contents

1. How This Document Is Organised
2. The Problem SOLID Solves: The Economics of Change
3. The Five Principles at a Glance
4. Foundational Vocabulary
5. Single Responsibility Principle (SRP)
6. Open/Closed Principle (OCP)
7. Liskov Substitution Principle (LSP)
8. Interface Segregation Principle (ISP)
9. Dependency Inversion Principle (DIP)
10. How the Five Principles Interact
11. Capstone: Refactoring an Order Processing System
12. SOLID Beyond Classes: Functions, Modules, and Services
13. Anti-Patterns and Misapplications
14. When SOLID Should Not Be Applied
15. Summary and Key Takeaways
16. Self-Assessment Questions with Answers
17. Practice Exercises with Solutions
18. Where SOLID Leads Next

1. How This Document Is Organised

Each of the five principles is presented using an identical ten-part structure. The uniformity is deliberate: once you internalise the structure, you can navigate any principle quickly and you can compare principles against each other along the same dimensions.

Every code example is written in Python 3. Abstract base classes are used to make contracts explicit, because explicit contracts are pedagogically clearer than implicit ones, even though Python’s duck typing would often permit the abstraction to be omitted. Section 8.7 discusses when the explicit form is worth its cost and when structural typing via typing.Protocol is preferable.

2. The Problem SOLID Solves: The Economics of Change

2.1 The observation behind the principles

A program is written once and modified many times. Industry studies of software cost consistently attribute the majority of total lifetime expenditure to maintenance rather than to initial construction. The practical consequence is that the dominant quality attribute of a codebase is not how quickly it was written but how cheaply it can be changed.

Definition (cost of change). The total effort required to implement a modification to a system, including the effort to understand the existing code, to write the modification, to update the affected tests, to verify that unrelated behaviour is unaffected, and to repair defects introduced by the modification.

SOLID is a set of five structural heuristics whose shared purpose is to reduce the cost of change. Each principle attacks the problem from a different direction, but the target is the same.

2.2 The four symptoms of degrading design

Robert C. Martin catalogued four observable symptoms that indicate a design is decaying. These are the diagnostic vocabulary of the rest of this document.

A fifth symptom, opacity, refers to code that is difficult to read and understand. Opacity is not addressed directly by SOLID, but it is usually reduced as a side effect, because each principle pushes toward smaller units with narrower purposes.

2.3 Coupling and cohesion: the underlying variables

Every SOLID principle can be restated as an instruction to lower coupling or raise cohesion. These two properties are therefore worth defining precisely before proceeding.

Definition (coupling). The degree of interdependence between two software modules. Module A is coupled to module B if a change to B can require a change to A. Coupling is measured by the number of assumptions A makes about B and by how specific those assumptions are.

Definition (cohesion). The degree to which the elements inside a single module belong together. A module is cohesive when its methods and fields all contribute to a single, well-defined purpose, and when removing any one of them would leave that purpose incomplete.

The design objective is low coupling and high cohesion. The two are related: when a module contains unrelated responsibilities (low cohesion), it necessarily accumulates dependencies belonging to all of them, which raises its coupling to the rest of the system.

Coupling comes in degrees, not merely in the binary of present or absent. The following ordering, from most damaging to least, is useful when judging a design.

The lower two rows are the targets. The Dependency Inversion Principle in Section 9 is precisely a technique for converting the upper rows into the bottom row.

2.4 Why object-oriented programming alone is not sufficient

Object-oriented programming supplies four mechanisms: encapsulation, abstraction, inheritance, and polymorphism. These are mechanisms, not policies. They determine what is expressible, not what is advisable.

Consider the analogy of a language and its grammar, which is used here because the correspondence is exact rather than decorative. Vocabulary determines which words exist; grammar determines which arrangements of those words produce meaning. A speaker who knows ten thousand words but no grammar produces sequences that are lexically valid and semantically useless. Object-oriented programming is the vocabulary of classes, methods, and inheritance relationships. SOLID is a grammar that constrains how those elements may be arranged so that the resulting structure remains comprehensible and modifiable.

Concretely, inheritance permits a subclass to override a method in a way that contradicts the parent’s guarantees; nothing in the language prevents it. Encapsulation permits a class to hide fifteen unrelated responsibilities behind a clean public interface; the compiler is satisfied. The mechanisms are neutral. SOLID supplies the missing judgement.

2.5 Historical origin

The principles were formulated separately over roughly two decades and later assembled under one acronym.

Martin collected the five in his writings during the late 1990s. Michael Feathers proposed the SOLID mnemonic in the early 2000s. The acronym imposes a memorable ordering but not a logical one: the principles were not designed as a sequence and need not be applied in the order S, O, L, I, D.

2.6 What the principles are, and what they are not

SOLID principles are heuristics, meaning rules of thumb that produce good outcomes in the majority of cases within their domain of applicability, but which admit exceptions and require judgement to apply. They are not theorems, not language rules, and not universal laws. A design that violates a SOLID principle is not automatically defective; it is a design that has accepted a specific risk, and the engineer should be able to state why that risk is acceptable.

Section 14 treats this point at length, because the most common failure mode among developers newly exposed to SOLID is not under-application but over-application.

3. The Five Principles at a Glance

Read the table once now and again after finishing Section 9. The second reading will carry substantially more information, which is a reasonable test of whether the intervening material has been absorbed.

4. Foundational Vocabulary

The five principles are stated in a compact technical vocabulary. Ambiguity in these terms is the primary cause of misapplication, so each is defined here and used consistently thereafter.

Two of these deserve immediate elaboration, because they are the most frequently confused.

Interface versus contract. An interface is a syntactic construct: a list of method names, parameters, and return types. A contract is a semantic one: it additionally specifies what the methods must actually do. A subclass can satisfy an interface perfectly while violating the contract, for instance by implementing withdraw(amount) with the correct signature but permitting the balance to go negative when the parent guaranteed it would not. The Liskov Substitution Principle in Section 7 is concerned with contracts, not interfaces, and this distinction is the entire subject of that section.

Policy versus mechanism. The distinction between high-level and low-level modules is not about position in a call stack or about how many lines of code a module contains. It is about whether the module states a rule of the business domain or a technique for accomplishing something. “Apply a 10 percent discount to premium customers” is policy and would remain true if the company migrated from PostgreSQL to DynamoDB. “Execute an INSERT statement against a PostgreSQL connection pool” is mechanism and has no meaning in the business domain. Policy is stable and valuable; mechanism is volatile and replaceable. The Dependency Inversion Principle in Section 9 exists to ensure that stable policy never depends on volatile mechanism.

5. Single Responsibility Principle (SRP)

5.1 Formal statement

“A class should have one, and only one, reason to change.”

Robert C. Martin

Martin later restated the principle in a form he considered less prone to misreading:

“A module should be responsible to one, and only one, actor.”

Both formulations are used below, because each clarifies a different aspect of the same idea.

5.2 Term-by-term interpretation

The principle contains three terms whose ordinary-language meanings are misleading in this context.

“Responsibility.” In SRP a responsibility is not a task, a method, or a feature. A responsibility is a reason to change, and a reason to change originates with a person or group who has the authority to request that change. Finance owns the rules for computing pay. Operations owns the rules for scheduling shifts. The database administration team owns the storage schema. Each of these is a distinct source of change requests.

“Reason to change.” This phrase is deliberately about causes, not effects. Two pieces of code that happen to change at the same time do not share a reason to change if the underlying causes are unrelated. Conversely, two pieces of code that change at different times can share a reason if both changes trace back to the same decision by the same group.

“One.” The principle does not restrict the number of methods, lines, or fields. A class with twenty methods that all serve a single purpose and all change together in response to requests from a single actor satisfies SRP. A class with two methods that answer to two different departments violates it.

Definition (Single Responsibility Principle). A module should have exactly one actor, meaning one person or group of stakeholders, whose changing requirements can cause that module to be modified.

5.3 The problem it solves

Consider what happens structurally when a single class answers to three actors. Every request from any of the three actors causes the same file to be edited. Three consequences follow mechanically.

Merge contention. Three teams edit the same file concurrently. Version control conflicts are frequent and their resolution requires someone who understands all three domains.

Unintended coupling of independent concerns. A change requested by Finance is deployed together with whatever half-finished work the Reporting team left in the same file. The two concerns share a release, a review, and a rollback unit even though they are logically unrelated. This is the mechanism by which fragility (Section 2.2) arises: the person changing the pay calculation had no reason to suspect the report generator, so they did not test it.

Loss of independent reusability. Another system needs only the pay calculation. Importing the class drags in the database driver and the PDF renderer, because they live in the same module. This is immobility.

The principle addresses all three by ensuring that the unit of code corresponds to the unit of organisational responsibility.

5.4 Worked violation

The following class is representative of code that accumulates naturally when features are added without periodic restructuring.

class Employee:
    """
    Represents an employee AND computes their pay AND persists them AND
    renders them into reports. The conjunction in that sentence is the defect.
    """

    def __init__(self, name, hours_worked, hourly_rate):
        self.name = name
        self.hours_worked = hours_worked
        self.hourly_rate = hourly_rate

    def calculate_pay(self):
        # Owned by Finance. Overtime rules, tax slabs, and bonus policy
        # will all eventually land inside this method.
        return self.hours_worked * self.hourly_rate

    def save(self):
        # Owned by the database team. The choice of engine, the schema,
        # the connection handling, and the retry policy all live here.
        print(f"INSERT INTO employees VALUES ('{self.name}', ...)")

    def generate_report(self, output_format):
        # Owned by the Reporting team. Layout, branding, and supported
        # export formats change on their schedule, not Finance's.
        if output_format == "pdf":
            print(f"Rendering PDF for {self.name}")
        elif output_format == "html":
            print(f"Rendering HTML for {self.name}")

5.5 Diagnosis

The diagnostic procedure is mechanical and should be applied literally rather than intuitively.

Step 1: List every method and ask who requests changes to it.

Step 2: Count the distinct actors. Three distinct actors implies three reasons to change, which implies three responsibilities in one class. The principle is violated.

Step 3: Verify by constructing a concrete failure scenario. Suppose Finance changes the overtime rule and, while editing the file, a developer alters a shared helper used by generate_report. The payroll test suite passes because it does not exercise reporting. The defect reaches production in a module that no one associated with the change. This scenario is not hypothetical; it is the standard mechanism by which fragility manifests.

There is a subtler diagnostic worth internalising. Examine which methods use which fields. In the class above, calculate_pay uses hours_worked and hourly_rate; generate_report uses only name. When the methods of a class partition cleanly into groups that touch disjoint sets of fields, the class is almost certainly implementing multiple responsibilities. This measure is formalised in the software metrics literature as Lack of Cohesion of Methods (LCOM), and while the numeric metric is rarely worth computing by hand, the underlying observation is a reliable signal.

5.6 Resolution

Each responsibility is extracted into a class whose name states its single purpose.

class Employee:
    """
    A pure data holder for employee attributes.

    Design decision: this class deliberately contains no behaviour beyond
    holding state. It changes only when the *definition* of an employee
    changes, for instance when HR introduces an employment-type field.
    It does not change when pay rules, storage, or report layouts change.
    """

    def __init__(self, name, hours_worked, hourly_rate):
        self.name = name
        self.hours_worked = hours_worked
        self.hourly_rate = hourly_rate


class PayrollCalculator:
    """
    Owns all monetary computation for employees. Answers to Finance.

    Overtime rules, tax handling, and bonus policy will be added here as
    the domain grows, and none of those additions can affect persistence
    or reporting, because this class shares no code with them.
    """

    OVERTIME_THRESHOLD_HOURS = 40
    OVERTIME_MULTIPLIER = 1.5

    def calculate_pay(self, employee):
        # The overtime split is expressed as explicit arithmetic rather
        # than a branch on hours, so that both components remain visible
        # and independently testable when tax rules are layered on later.
        regular_hours = min(employee.hours_worked, self.OVERTIME_THRESHOLD_HOURS)
        overtime_hours = max(0, employee.hours_worked - self.OVERTIME_THRESHOLD_HOURS)

        regular_pay = regular_hours * employee.hourly_rate
        overtime_pay = overtime_hours * employee.hourly_rate * self.OVERTIME_MULTIPLIER
        return regular_pay + overtime_pay


class EmployeeRepository:
    """
    Owns persistence of employees. Answers to the database team.

    The name 'Repository' is conventional and signals a specific contract:
    this class translates between domain objects and storage, and it
    contains no business rules. A tax calculation appearing in this class
    would itself be an SRP violation.
    """

    def save(self, employee):
        print(f"Persisting {employee.name}")

    def find_by_name(self, name):
        print(f"Loading {name}")


class PayslipRenderer:
    """
    Owns presentation of employee pay. Answers to Reporting.

    Note that this class receives the already-computed pay rather than an
    Employee, so that it has no opportunity to recompute or reinterpret
    monetary values. Keeping the calculation out of the renderer is what
    prevents the two responsibilities from silently merging again.
    """

    def render(self, employee, net_pay, output_format):
        if output_format == "pdf":
            print(f"PDF payslip for {employee.name}: {net_pay}")
        elif output_format == "html":
            print(f"HTML payslip for {employee.name}: {net_pay}")

The coordination that previously lived inside Employee now lives at the call site or in an explicit orchestrator.

employee = Employee("Ananya", hours_worked=45, hourly_rate=500)

calculator = PayrollCalculator()
repository = EmployeeRepository()
renderer = PayslipRenderer()

net_pay = calculator.calculate_pay(employee)
repository.save(employee)
renderer.render(employee, net_pay, output_format="pdf")

The effect on blast radius is the point of the exercise and can be tabulated.

The final row is instructive. Adding a field genuinely does touch two classes, because storage must know about the new field. SRP does not promise that every change touches exactly one file; it promises that each file changes for exactly one reason. The repository changes because storage rules changed, which is its own reason.

5.7 Alternative techniques for the same goal

Extracting classes is the standard resolution, but it is not the only one, and choosing it reflexively is itself a mistake.

Module-level separation without new classes. In a small program, moving calculate_pay, save, and render into three separate modules as plain functions achieves the same separation of change reasons at lower ceremony. Python’s module system is a first-class unit of encapsulation, and a function in payroll.py is separated from a function in storage.py just as effectively as two classes would be. Classes earn their place when the behaviour needs configuration, state, or polymorphic substitution.

The Facade pattern to preserve caller convenience. Splitting a class multiplies the number of objects a caller must assemble. When the original single-call convenience matters, a thin facade restores it without recombining the responsibilities.

class PayrollService:
    """
    A facade that orchestrates the specialised collaborators.

    This class has exactly one reason to change: the *sequence* of steps
    in the payroll workflow. It contains no pay arithmetic, no SQL, and no
    formatting, so a change to any of those does not reach it.
    """

    def __init__(self, calculator, repository, renderer):
        self.calculator = calculator
        self.repository = repository
        self.renderer = renderer

    def process(self, employee, output_format="pdf"):
        net_pay = self.calculator.calculate_pay(employee)
        self.repository.save(employee)
        self.renderer.render(employee, net_pay, output_format)
        return net_pay

The facade is worth studying because it demonstrates that “orchestrating a workflow” is itself a legitimate single responsibility. The workflow changes when the business changes the order or composition of steps, which is a genuine and distinct reason to change.

Deliberate non-separation for value objects. A class such as Money or Date may legitimately contain arithmetic, comparison, parsing, and formatting. These appear to be several responsibilities but are all owned by the same actor, namely whoever defines what money or a date means in the domain, and they all change together. Splitting them would produce anaemic fragments and increase, not decrease, the cost of change.

The following table summarises the decision.

5.8 Costs and limits

SRP is not free, and the costs are the reason it must be applied with judgement.

Increased indirection. After splitting, understanding the payroll flow requires reading four files instead of one. For a reader unfamiliar with the codebase this is a genuine comprehension cost. The cost is worth paying when the classes change independently; it is pure overhead when they do not.

Anaemic domain models. Aggressively stripping behaviour from entities produces classes that are little more than dictionaries with attribute access, while all logic accumulates in service classes. This is a recognised anti-pattern, because it discards the principal benefit of object orientation, namely the co-location of data with the operations that maintain its invariants. Behaviour that enforces an entity’s own invariants, such as Order.add_item rejecting a negative quantity, belongs on the entity. Behaviour that coordinates across entities or reaches outside the process belongs elsewhere.

Premature decomposition. Splitting a class before the axes of change are known frequently produces the wrong split, and an incorrect boundary is more expensive than no boundary, because it must first be dismantled before the correct one can be created.

5.9 Detection heuristics

The fourth and sixth signals deserve emphasis because they are empirical rather than speculative. Running git log --format=format: --name-only | sort | uniq -c | sort -rg | head -20 over a repository lists the files that change most often. Those files are the practical candidates for SRP analysis, since they are where the cost of poor separation is actually being paid.

5.10 Checkpoint questions

Q1. A ShoppingCart class exposes add_item, remove_item, update_quantity, apply_coupon, subtotal, and clear. Six public methods. Does this violate SRP?

Q2. A developer splits a 300-line ReportGenerator into ReportGeneratorPartOne and ReportGeneratorPartTwo, each 150 lines. Has SRP been applied?

Q3. Two classes, InvoiceCalculator and TaxCalculator, are always modified in the same commit. Does this prove an SRP violation?

6. Open/Closed Principle (OCP)

6.1 Formal statement

“Software entities (classes, modules, functions) should be open for extension, but closed for modification.”

Bertrand Meyer, Object-Oriented Software Construction, 1988

6.2 Term-by-term interpretation

“Open for extension.” The behaviour of the module can be augmented. New cases, new variants, and new capabilities can be introduced.

“Closed for modification.” The augmentation is achieved without editing the module’s existing source code. Its file remains untouched, its compiled artefact remains valid, and its existing tests remain relevant without revision.

The two clauses appear contradictory, since adding behaviour to something usually means changing it. The contradiction dissolves once a level of indirection is introduced. The module is written against an abstraction; new behaviour arrives as a new implementation of that abstraction; the module never learns that the new implementation exists. Polymorphic dispatch is the mechanism that makes the apparent contradiction tractable, which is why OCP cannot be discussed independently of polymorphism.

Definition (Open/Closed Principle). A module satisfies OCP with respect to a particular axis of change if new variations along that axis can be added by writing new code rather than by editing existing code.

The qualifier “with respect to a particular axis of change” is essential and is omitted in most informal presentations. No module can be closed against every conceivable change. A discount system may be closed against the addition of new discount types while remaining wide open to a change in the signature of the discount calculation itself. Meyer’s principle is therefore a directive to identify the axes along which change is likely and to arrange the design so that those specific axes require extension rather than modification.

6.3 The problem it solves

Modifying working code carries a category of risk that adding new code does not.

Adding a new class that no existing code references carries none of these risks in principle. The existing code cannot behave differently, because it has not changed. Verification of the new class is confined to the new class. This asymmetry between modification and addition is the entire economic argument for OCP.

6.4 Worked violation

class DiscountCalculator:
    """Computes a discount based on the customer's category."""

    def calculate(self, customer_type, amount):
        if customer_type == "regular":
            return amount * 0.05
        elif customer_type == "premium":
            return amount * 0.10
        elif customer_type == "vip":
            return amount * 0.20
        else:
            return 0

The requirement history of such a class is predictable. A corporate tier is introduced at 15 percent, so an elif is added. A student tier follows at 8 percent. A first-purchase promotion is introduced, which is not a customer type at all but a condition, so a boolean parameter is threaded through the signature. A regional festival discount is added, requiring a date parameter. Within a year the method is several hundred lines long, its parameter list encodes four orthogonal concerns, and no developer can modify one branch with confidence that the others are unaffected.

Observe precisely which property has been lost. Each new customer type requires editing a file that already contains working, tested logic for every previous customer type. The blast radius of adding a customer type is the entire discount subsystem.

6.5 Diagnosis

The conditional-on-type test. Locate every conditional that branches on a type, a category name, an enumeration value, or a string tag. Each such conditional is a point at which the addition of a new value forces modification of existing code. This is the single most reliable indicator of an OCP violation.

The shotgun surgery test. Trace what a realistic new requirement would touch. If adding one conceptual thing, such as a customer tier, requires edits at several locations, and especially if it requires edits in several files that must be kept mutually consistent, the design is not closed along that axis. The failure mode where a developer updates three of the four required locations and ships a partially implemented tier is the direct consequence.

Distinguishing genuine violations from acceptable conditionals. Not every conditional is an OCP violation. A conditional is a violation when it branches on a set of values that is expected to grow. A conditional that branches on a genuinely fixed set, such as the three possible outcomes of a comparison, is stable and should not be replaced with polymorphism.

6.6 Resolution

The resolution introduces an abstraction that represents the varying concept, then supplies one implementation per variant.

from abc import ABC, abstractmethod


class DiscountPolicy(ABC):
    """
    The stable abstraction. Everything that varies between customer tiers
    is pushed behind this single method, and everything that does not vary
    stays in the calling code.

    Naming note: 'Policy' rather than 'Strategy' is used here because the
    concept is a business rule. The structural pattern is identical to the
    Strategy pattern, which is examined in the behavioural patterns
    document; OCP is the principle, Strategy is one pattern that realises it.
    """

    @abstractmethod
    def discount_for(self, amount: float) -> float:
        """
        Return the absolute discount amount, not the discounted total.

        Contract note: returning the discount rather than the final price
        means the caller retains control over how the discount is applied,
        combined with other discounts, or reported. Returning the final
        price would have embedded that decision inside every policy and
        made discount stacking impossible to implement later.
        """
        ...


class RegularCustomerDiscount(DiscountPolicy):
    def discount_for(self, amount):
        return amount * 0.05


class PremiumCustomerDiscount(DiscountPolicy):
    def discount_for(self, amount):
        return amount * 0.10


class VIPCustomerDiscount(DiscountPolicy):
    def discount_for(self, amount):
        return amount * 0.20


class NoDiscount(DiscountPolicy):
    """
    The Null Object variant. Its existence removes the need for callers to
    check whether a policy is present, which eliminates a null check at
    every call site and prevents the reappearance of conditionals in the
    client code.
    """

    def discount_for(self, amount):
        return 0.0

The consuming code is written once against the abstraction and is then never modified again on this axis.

class Checkout:
    def final_price(self, amount: float, policy: DiscountPolicy) -> float:
        # This method contains no knowledge of which policies exist. Adding
        # a hundred new policies leaves this line untouched, which is the
        # operational meaning of "closed for modification".
        return amount - policy.discount_for(amount)

Introducing a corporate tier is now purely additive.

class CorporateDiscount(DiscountPolicy):
    """
    Added later. No existing file was edited to introduce this class,
    so no existing test could have been invalidated by its addition.
    """

    def discount_for(self, amount):
        return amount * 0.15

6.7 Alternative techniques for the same goal

Polymorphic classes are the canonical realisation of OCP, but several alternatives achieve extensibility at different cost and expressiveness points. Selecting among them is a genuine engineering decision.

Alternative 1: dictionary dispatch. The mapping from key to behaviour is stored in a data structure rather than encoded in control flow.

DISCOUNT_RATES = {
    "regular": 0.05,
    "premium": 0.10,
    "vip": 0.20,
}


def discount_for(customer_type: str, amount: float) -> float:
    # Adding a tier means adding a dictionary entry. The function is
    # untouched, so it is closed for modification along this axis.
    return amount * DISCOUNT_RATES.get(customer_type, 0.0)

This is appropriate when every variant differs only by a value. It becomes unsuitable the moment a variant needs behaviour rather than a constant, for example a tier whose discount is capped at a maximum amount or depends on order history.

Alternative 2: first-class functions. Python treats functions as objects, so a policy can be a function rather than a class instance.

def regular_discount(amount):
    return amount * 0.05


def volume_discount(amount):
    # Behaviour, not merely a constant, so the dictionary-of-rates approach
    # would not have accommodated this variant.
    return amount * 0.15 if amount > 100_000 else amount * 0.05


def final_price(amount, discount_fn):
    return amount - discount_fn(amount)

The trade-off is explicit. Functions are lighter, require no class declaration, and are trivially testable. They lose the formal contract that an abstract base class enforces, they cannot hold configured state without closures, and they cannot be extended with additional operations later without changing every call site. Functions are preferable when the abstraction has exactly one operation and no state; classes are preferable otherwise.

Alternative 3: registry with self-registration. The set of implementations is discovered rather than enumerated, which closes the composition root as well as the consuming code.

class DiscountRegistry:
    """
    Maps a tier name to a policy instance.

    Without a registry, some module must contain a mapping from string to
    class, and that mapping is itself a place that must be edited whenever
    a tier is added. The registry moves that edit into the new class's own
    file, so the addition remains confined to a single new file.
    """

    _policies: dict = {}

    @classmethod
    def register(cls, tier_name):
        def decorator(policy_class):
            cls._policies[tier_name] = policy_class()
            return policy_class
        return decorator

    @classmethod
    def get(cls, tier_name) -> DiscountPolicy:
        return cls._policies.get(tier_name, NoDiscount())


@DiscountRegistry.register("corporate")
class CorporateDiscountV2(DiscountPolicy):
    def discount_for(self, amount):
        return amount * 0.15

The cost of a registry is reduced traceability: static analysis and simple text search no longer reveal where a policy is used, because the connection is made at runtime. Registries are justified in plugin architectures and frameworks, where the set of implementations is genuinely open-ended and may be supplied by third parties. They are over-engineering for a fixed internal set of five tiers.

Alternative 4: accepting the conditional. When the set of variants is small, stable, and unlikely to grow, an if statement is the correct design. It is shorter, immediately readable, and imposes no indirection. The engineering error is not the use of a conditional; it is the use of a conditional along an axis that is known to be growing.

The following table summarises the selection criteria.

6.8 Costs and limits

Every abstraction is a bet on a predicted axis of change. If the prediction is correct, the abstraction pays for itself the first time a variant is added. If the prediction is wrong, the codebase carries permanent indirection that serves nothing and obstructs the change that actually arrives. Predicting the wrong axis is a common and expensive error, which is why the widely quoted guideline is to write the conditional first and introduce the abstraction when the second or third variant appears. By then the axis is established by evidence rather than by speculation.

Closing one axis usually opens another. In the discount example, the design is now closed against new tiers but open to modification if the discount_for signature must change, since every implementation would then require editing. Abstractions redistribute the cost of change; they do not eliminate it. Choosing which axis to protect is therefore a decision about which changes are most probable.

Indirection has a comprehension cost. Tracing a call through an abstract base class to an unknown implementation is harder than reading a conditional. In a codebase with dozens of unnecessary abstractions, this cost accumulates into the opacity described in Section 2.2.

6.9 Detection heuristics

6.10 Checkpoint questions

Q1. A function branches on three cases: less than, equal to, and greater than. Does this violate OCP?

Q2. After refactoring to polymorphic discount policies, some code must still decide which policy object to construct for a given customer. Has the conditional simply moved rather than disappeared?

Q3. A codebase has one discount type and the product manager states no others are planned. Should the polymorphic design be applied?

7. Liskov Substitution Principle (LSP)

7.1 Formal statement

“Let φ(x) be a property provable about objects x of type T. Then φ(y) should be true for objects y of type S where S is a subtype of T.”

Barbara Liskov and Jeannette Wing, A Behavioral Notion of Subtyping, 1994

The engineering restatement, which is the form used in practice:

Code written against a base type must continue to behave correctly when given any subtype, without knowing that it received a subtype.

7.2 Term-by-term interpretation

“Property provable about objects of type T.” This includes every guarantee a caller may legitimately rely upon: the range of accepted inputs, the guarantees on returned values, the exceptions that may be raised, the invariants maintained across the object’s lifetime, and the observable effects of calling methods in a particular order. It does not include implementation details such as which algorithm is used internally.

“Subtype.” Liskov’s notion of subtype is behavioural, not syntactic. Declaring class Square(Rectangle) establishes a syntactic subtype relationship in Python. Whether Square is a behavioural subtype of Rectangle is a separate question decided entirely by whether the contract is preserved. LSP asserts that the syntactic relationship should be created only when the behavioural relationship holds.

Definition (behavioural subtyping). Type S is a behavioural subtype of type T if every program that is correct when using instances of T remains correct when those instances are replaced by instances of S.

Definition (Liskov Substitution Principle). Inheritance should be used only when the derived type is a behavioural subtype of the base type. Where the behavioural relationship does not hold, the inheritance relationship must not be declared.

7.3 The rules that constitute the contract

Liskov and Wing decomposed behavioural subtyping into a small set of verifiable conditions. These are the operational form of the principle and the checklist that should be applied to any proposed override.

The last two rules follow directly from the first two. A narrower parameter type is a strengthened precondition; a broader return type is a weakened postcondition. They are listed separately because type checkers can verify them mechanically while the behavioural rules generally cannot be verified automatically.

A memory device that captures the asymmetry: a subtype may demand less and deliver more, never the reverse.

7.4 Worked violation 1: the Square and Rectangle problem

This example is canonical because it demonstrates that a relationship which is true in the problem domain can be false in the behavioural domain.

class Rectangle:
    """
    Contract: width and height are independently mutable. Setting one
    has no effect on the other. This guarantee is not written in any
    method signature, yet every caller depends on it.
    """

    def __init__(self, width, height):
        self._width = width
        self._height = height

    def set_width(self, width):
        self._width = width

    def set_height(self, height):
        self._height = height

    def area(self):
        return self._width * self._height


class Square(Rectangle):
    """
    Mathematically a square is a rectangle, so inheritance appears
    justified. The invariant width == height must be maintained, which
    forces each setter to modify both dimensions.
    """

    def __init__(self, side):
        super().__init__(side, side)

    def set_width(self, width):
        self._width = width
        self._height = width      # Silently violates the independence guarantee

    def set_height(self, height):
        self._width = height
        self._height = height

The violation becomes observable in any client written against the base contract.

def resize_and_verify(rectangle: Rectangle):
    """
    A perfectly reasonable function written against Rectangle's contract.
    It relies only on the independence of width and height, which the
    base class guarantees.
    """
    rectangle.set_width(10)
    rectangle.set_height(5)
    assert rectangle.area() == 50, f"Expected 50, computed {rectangle.area()}"


resize_and_verify(Rectangle(1, 1))   # Passes: area is 50
resize_and_verify(Square(1))         # Fails: area is 25

The failure is not in Square considered in isolation, which is internally consistent, nor in resize_and_verify, which uses only documented behaviour. The failure is in the declaration that Square is a subtype of Rectangle. Square strengthens an invariant, namely that the two dimensions are always equal, and any strengthened invariant on a mutable object is visible to clients as weakened postconditions on the setters.

A widespread misdiagnosis holds that the problem is mathematical. It is not. Geometry is untouched. The problem is that Rectangle was defined as a mutable type with independent dimensions, and that specific contract admits no square. The following demonstrates the point by changing the contract rather than the geometry.

class ImmutableRectangle:
    """
    With no setters, the independence guarantee has no observable
    consequence, because dimensions can never be changed after
    construction. The contract that Square violated no longer exists.
    """

    def __init__(self, width, height):
        self._width = width
        self._height = height

    @property
    def width(self):
        return self._width

    @property
    def height(self):
        return self._height

    def area(self):
        return self._width * self._height

    def with_width(self, width):
        # Returns a new object rather than mutating this one. A subtype
        # can legitimately return a different concrete type here as long
        # as it remains an ImmutableRectangle.
        return ImmutableRectangle(width, self._height)


class ImmutableSquare(ImmutableRectangle):
    """
    A legitimate behavioural subtype. Every guarantee ImmutableRectangle
    makes is upheld, because there is no mutation through which the
    equality invariant could surprise a caller.
    """

    def __init__(self, side):
        super().__init__(side, side)

The lesson generalises well beyond this example: mutability is what converts a benign specialisation into an LSP violation, because mutation is the mechanism by which a subtype’s stricter invariant becomes observable to a client that did not expect it.

7.5 Resolution options for the Square and Rectangle problem

Three resolutions are available, and the choice among them is determined by how the types are actually used.

Option 1: eliminate the inheritance relationship. Model both as independent implementations of a shared abstraction that promises only what both can deliver.

from abc import ABC, abstractmethod


class Shape(ABC):
    """
    The abstraction promises only area computation, which both shapes can
    honour unconditionally. Nothing about mutable dimensions is promised,
    so nothing about mutable dimensions can be violated.
    """

    @abstractmethod
    def area(self) -> float:
        ...


class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height


class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side ** 2

Option 2: make the base type immutable, as shown in Section 7.4. Appropriate when the domain naturally treats shapes as values rather than as entities with identity and mutable state.

Option 3: weaken the base contract explicitly. If Rectangle documents that setting width may adjust height in some subtypes, then Square no longer violates anything. This resolution is technically valid and almost always undesirable, because the base contract has become so weak that clients can rely on nothing, and the value of the abstraction collapses.

7.6 Worked violation 2: the unsupported operation

The second canonical violation occurs when a subtype cannot perform an operation the base type declares.

class Bird:
    def fly(self):
        print("Flying")


class Penguin(Bird):
    def fly(self):
        # Violates the exception constraint. The base contract states that
        # fly() succeeds; this subtype converts a normal call into a crash.
        raise NotImplementedError("Penguins cannot fly")

Any generic loop over birds now fails on a subset of its inputs, which forces callers to reintroduce type checks and thereby destroys the benefit of polymorphism.

The correct resolution is to restructure the hierarchy so that each abstraction promises only what all of its subtypes can deliver.

from abc import ABC, abstractmethod


class Bird(ABC):
    """
    The abstraction is narrowed to locomotion in general, which every bird
    supports. Flight is not part of the base contract because it is not
    universal among birds.
    """

    @abstractmethod
    def move(self) -> None:
        ...


class FlyingBird(Bird):
    def move(self):
        self.fly()

    def fly(self):
        print("Flying")


class FlightlessBird(Bird):
    def move(self):
        print("Walking")


class Sparrow(FlyingBird):
    pass


class Penguin(FlightlessBird):
    def move(self):
        print("Swimming")     # Legitimate override: still locomotion, contract intact

Code that requires flight now declares FlyingBird in its parameter type, and the type system prevents a penguin from reaching it. Code that requires only locomotion declares Bird and accepts every subtype safely.

The general principle extracted from this example: an abstraction must promise only the intersection of what all its implementations can deliver, never the union. Promising the union guarantees that some implementation will have to break the contract.

7.7 Violations that are not violations

Several patterns superficially resemble LSP violations but do not violate the principle. Recognising them prevents unnecessary refactoring.

Adding new methods. A subtype may introduce operations the base type does not declare. Existing clients cannot call methods they do not know about, so no existing guarantee is affected.

Changing the implementation while preserving guarantees. A subtype may sort using a different algorithm, cache results, log calls, or open a network connection. As long as the observable contract holds, the substitution is safe. This is exactly why the Decorator and Proxy patterns are legitimate.

Returning a more specific type. Covariant returns strengthen the postcondition and are permitted.

Accepting a broader parameter type. Contravariant parameters weaken the precondition and are permitted.

The following pair illustrates the boundary precisely.

class FileReader:
    def read(self, path: str) -> str:
        with open(path) as handle:
            return handle.read()


class LoggingFileReader(FileReader):
    """
    Does NOT violate LSP. A side effect is added, but every path the parent
    accepts is still accepted, and the returned content is unchanged.
    """

    def read(self, path):
        print(f"Reading {path}")
        return super().read(path)


class TextOnlyFileReader(FileReader):
    """
    VIOLATES LSP. The precondition has been strengthened from "any readable
    path" to "any readable path ending in .txt". A client that worked with
    the parent will crash when handed this subtype and a JSON file.
    """

    def read(self, path):
        if not path.endswith(".txt"):
            raise ValueError("Only .txt files are supported")
        return super().read(path)

7.8 LSP in Python specifically

Python’s dynamic typing changes how violations are detected, not whether they matter.

No compile-time enforcement. Python performs no static verification of overrides by default. A subclass may change a method’s signature entirely and the interpreter will accept it. Violations therefore surface at runtime, typically in production, and typically in code far from the subclass that caused them.

Static type checkers verify the mechanical rules. Tools such as mypy verify parameter contravariance and return covariance when type annotations are present. They cannot verify behavioural rules such as invariant preservation, because those are semantic rather than syntactic. Type annotations therefore catch a useful subset of LSP violations at low cost, and behavioural violations remain the responsibility of design review and tests.

Duck typing narrows the scope of the problem. When a function accepts any object exposing a read method, no inheritance relationship is declared and the base contract is defined implicitly by what the function actually requires. This does not eliminate LSP concerns; it relocates them. The implicit contract still exists, and an object that exposes read but returns an integer instead of a string still breaks callers. typing.Protocol makes such implicit contracts explicit without requiring inheritance, and is discussed in Section 8.7.

Contract tests are the practical enforcement mechanism. Because Python cannot verify behavioural contracts, the standard technique is to write one test suite against the abstraction and run it against every implementation.

import pytest


class DiscountPolicyContract:
    """
    A reusable contract test. Every concrete policy must pass every test
    defined here, which turns the informal contract into an executable one.

    Design note: this class is deliberately not named with a Test prefix,
    so the test runner does not attempt to execute it directly. Subclasses
    supply the implementation under test and inherit the assertions.
    """

    def create_policy(self):
        raise NotImplementedError("Subclasses supply the implementation")

    def test_discount_is_never_negative(self):
        policy = self.create_policy()
        assert policy.discount_for(1000) >= 0

    def test_discount_never_exceeds_the_amount(self):
        policy = self.create_policy()
        assert policy.discount_for(1000) <= 1000

    def test_zero_amount_yields_zero_discount(self):
        policy = self.create_policy()
        assert policy.discount_for(0) == 0


class TestVIPDiscount(DiscountPolicyContract):
    def create_policy(self):
        return VIPCustomerDiscount()


class TestCorporateDiscount(DiscountPolicyContract):
    def create_policy(self):
        return CorporateDiscount()

Any future implementation that violates the shared contract fails the inherited tests immediately, at the point where the violation was introduced rather than at the point where a client happens to encounter it.

7.9 Costs and limits

Contracts must be documented to be enforceable. LSP presupposes that the base type’s guarantees are known. In practice, many base classes carry undocumented guarantees that clients discovered empirically. A subtype author cannot preserve a contract that was never stated, so writing contracts down is a precondition for applying the principle at all.

Strict application discourages inheritance broadly. Applied rigorously, LSP eliminates most inheritance hierarchies, because genuine behavioural subtyping is rarer than it appears. This is generally a benefit rather than a cost. Composition and delegation avoid the entire class of problems, which is the basis of the long-standing guidance to prefer composition over inheritance.

Some violations are economically acceptable. A subtype that violates a rarely exercised guarantee in an internal tool may be cheaper to tolerate than to restructure. The requirement is that the violation be identified, documented, and consciously accepted, rather than discovered later as a production defect.

7.10 Detection heuristics

7.11 Checkpoint questions

Q1. A CachingRepository subclasses Repository and returns cached results rather than querying storage on every call. Does this violate LSP?

Q2. A subclass overrides a method to accept Iterable where the parent accepted list. Is this permitted?

Q3. Stack inherits from list in order to reuse append and pop. What is the LSP concern?

8. Interface Segregation Principle (ISP)

8.1 Formal statement

“Clients should not be forced to depend upon interfaces that they do not use.”

Robert C. Martin

8.2 Term-by-term interpretation

“Client.” The calling code, not the implementing class. ISP is stated from the perspective of the consumer. This orientation is what distinguishes ISP from SRP and is the most frequently missed aspect of the principle.

“Forced to depend upon.” A client depends on every method declared in the interface it references, whether or not it calls them. The dependency is real even when unused, because a change to any method in that interface, including a signature change or the addition of a new abstract method, propagates to everyone who references the interface.

“Interfaces they do not use.” Methods present in the declared type but irrelevant to the particular client.

Definition (fat interface). An interface that aggregates operations serving several distinct client groups, such that no single client uses more than a fraction of it.

Definition (Interface Segregation Principle). Wide interfaces should be decomposed into several narrow, client-specific interfaces, so that each client depends only on the operations it actually invokes.

8.3 The problem it solves

Two distinct costs arise from fat interfaces, and they affect implementers and clients respectively.

Cost imposed on implementers. A class that can perform only part of the interface must nonetheless supply every declared method. The residual methods become stubs that raise exceptions or return meaningless values, which is simultaneously an LSP violation, since the object cannot honour the contract it advertises. This is the mechanism by which ISP violations manufacture LSP violations, and it explains why the two principles are almost always discussed together.

Cost imposed on clients. A client that requires one operation but declares a dependency on a twelve-method interface is coupled to eleven methods it never invokes. Three concrete consequences follow. Recompilation and redeployment are triggered by changes the client does not care about. Test doubles must implement all twelve methods, making every test more expensive to write and more fragile. The reader of the client code cannot determine from the type declaration what the client actually needs, which obscures the true dependency structure of the system.

8.4 Worked violation

from abc import ABC, abstractmethod


class OfficeMachine(ABC):
    """
    A single abstraction covering every capability any office device might
    have. The defect is that no real device has all of them.
    """

    @abstractmethod
    def print_document(self, document): ...

    @abstractmethod
    def scan_document(self, document): ...

    @abstractmethod
    def fax_document(self, document): ...

    @abstractmethod
    def staple(self, document): ...


class AllInOnePrinter(OfficeMachine):
    """Satisfies the interface honestly, since it genuinely has every capability."""

    def print_document(self, document): print(f"Printing {document}")
    def scan_document(self, document): print(f"Scanning {document}")
    def fax_document(self, document): print(f"Faxing {document}")
    def staple(self, document): print(f"Stapling {document}")


class BudgetPrinter(OfficeMachine):
    """
    Cannot honour three quarters of the contract it advertises. The stubs
    are not a cosmetic problem: any client holding this object as an
    OfficeMachine may legally call scan_document and will crash.
    """

    def print_document(self, document): print(f"Printing {document}")
    def scan_document(self, document): raise NotImplementedError
    def fax_document(self, document): raise NotImplementedError
    def staple(self, document): raise NotImplementedError

The client-side cost is equally concrete.

def print_all(documents, machine: OfficeMachine):
    # This function uses exactly one of the four declared operations, yet it
    # is coupled to all four. Adding a fifth abstract method to OfficeMachine
    # would break every test double written for this function, even though
    # the function's own behaviour is unaffected.
    for document in documents:
        machine.print_document(document)

8.5 Diagnosis

Step 1: build a client-to-method usage matrix. For each client of the interface, record which methods it invokes.

Step 2: examine the pattern. A diagonal pattern, in which each client uses a different single method, is definitive evidence that the interface is an arbitrary aggregation rather than a coherent abstraction. A dense matrix, in which most clients use most methods, indicates a genuinely cohesive interface that should not be split.

Step 3: count the stubs. Every method in every implementation that raises, returns a placeholder, or does nothing is a location where the interface promised something the implementer cannot deliver.

8.6 Resolution

The interface is decomposed along the boundaries revealed by the usage matrix, and implementations compose the capabilities they actually possess.

from abc import ABC, abstractmethod


class Printer(ABC):
    @abstractmethod
    def print_document(self, document): ...


class Scanner(ABC):
    @abstractmethod
    def scan_document(self, document): ...


class FaxMachine(ABC):
    @abstractmethod
    def fax_document(self, document): ...


class Stapler(ABC):
    @abstractmethod
    def staple(self, document): ...


class BudgetPrinter(Printer):
    """
    Declares exactly one capability and implements it. There is no stub,
    no exception, and no possibility of a client calling an operation this
    device cannot perform, because the type system prevents it.
    """

    def print_document(self, document):
        print(f"Printing {document}")


class AllInOnePrinter(Printer, Scanner, FaxMachine, Stapler):
    """
    Multiple inheritance is used here as interface composition rather than
    implementation reuse. Each base contributes one abstract method and no
    state, so the diamond and initialisation problems associated with
    multiple inheritance of concrete classes do not arise.
    """

    def print_document(self, document): print(f"Printing {document}")
    def scan_document(self, document): print(f"Scanning {document}")
    def fax_document(self, document): print(f"Faxing {document}")
    def staple(self, document): print(f"Stapling {document}")

Clients now declare precisely what they need.

def print_all(documents, machine: Printer):
    # The signature now documents the actual requirement. A reader learns
    # from the type alone that this function neither scans nor faxes, and a
    # test double needs exactly one method.
    for document in documents:
        machine.print_document(document)


def archive(documents, scanner: Scanner):
    for document in documents:
        scanner.scan_document(document)


def print_and_staple(documents, machine):
    """
    A client requiring two capabilities. Python's structural flexibility
    permits passing any object that has both methods; a statically checked
    version would declare an intersection type or a dedicated Protocol.
    """
    for document in documents:
        machine.print_document(document)
        machine.staple(document)

8.7 Alternative techniques and the Python-specific dimension

Role interfaces versus header interfaces. Martin Fowler distinguishes two styles of interface definition, and the distinction is the practical core of ISP.

ISP is effectively an instruction to define role interfaces. The practical technique is to name the interface after the capability the client requires, not after the class that happens to provide it. Printer is a role; HPLaserJetInterface is a header.

Client-owned interfaces. A stronger form of the same idea places the interface definition in the client’s module rather than the implementer’s. The client declares what it needs; the implementer conforms. This inverts the ownership of the abstraction and is the structural basis of the ports and adapters architecture discussed in Section 9.8.

typing.Protocol as the Pythonic realisation. Python 3.8 introduced structural subtyping through typing.Protocol, which allows an interface to be declared and statically checked without any inheritance relationship.

from typing import Protocol


class SupportsPrint(Protocol):
    """
    A structural interface. Any object with a matching print_document
    method satisfies it, with no inheritance and no import dependency from
    the implementer to this declaration.

    This is the strongest available form of ISP in Python: the client
    declares its requirement, implementations remain entirely unaware of
    the declaration, and mypy still verifies conformance statically.
    """

    def print_document(self, document) -> None: ...


def print_all(documents, machine: SupportsPrint) -> None:
    for document in documents:
        machine.print_document(document)

The trade-off between the two mechanisms is worth stating precisely.

Duck typing without any declaration. Passing an object and calling a method, with no interface declared at all, is the lightest option and remains common in Python. The interface still exists; it is simply implicit and undocumented. This is acceptable for small internal code and unsuitable for module boundaries, where the absence of a written contract makes both LSP verification and safe evolution impossible.

8.8 Costs and limits

Interface proliferation. Segregating without evidence produces dozens of single-method interfaces, each with one implementation and one client. This is not modularity; it is indirection without benefit. The correct trigger for segregation is the observed existence of distinct client groups with distinct needs, demonstrated by the usage matrix of Section 8.5.

Composition complexity at the point of use. When a client legitimately needs three capabilities, it must express a compound requirement. Python has no first-class intersection type, so the options are a combined Protocol, multiple parameters, or an untyped parameter with a documented expectation. Each of these carries some awkwardness.

Segregation does not reduce total surface area. Splitting one four-method interface into four one-method interfaces leaves the same number of methods in the system. The benefit is in the dependency graph, not in the amount of code. If no client actually benefits from the narrower dependency, the split has produced cost with no return.

8.9 Detection heuristics

8.10 Checkpoint questions

Q1. An interface has eight methods and every one of its four clients uses all eight. Does this violate ISP?

Q2. How are ISP and SRP different, given that both push toward smaller units?

Q3. In Python, where duck typing means a function can simply call whatever method it needs, is ISP still relevant?

9. Dependency Inversion Principle (DIP)

9.1 Formal statement

“A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend on details. Details should depend on abstractions.”

Robert C. Martin

9.2 Term-by-term interpretation

The definitions of high-level module, low-level module, abstraction, and concretion were established in Section 4 and are used here without restatement.

Clause A prohibits a direct dependency from policy to mechanism. The business rule must not name the database driver.

Clause B is the clause that gives the principle its name and is the one most often overlooked. It states that the abstraction must be defined in terms of the domain rather than in terms of any particular implementation. An interface named Repository with a method save(entity) satisfies clause B. An interface named Repository with a method execute_sql(query) does not, because although it is technically abstract, its vocabulary is that of a relational database and no document store could implement it sensibly. Such an interface is a leaky abstraction: it has inverted the syntax of the dependency while preserving its semantics.

“Inversion.” The term is comparative and refers to the reversal of the conventional layered dependency direction. In traditional layered design, the dependency arrows point downward from user interface to business logic to data access. DIP reverses the lower arrow so that data access depends on business logic through an abstraction that business logic owns.

Definition (Dependency Inversion Principle). Source-level dependencies should point toward abstractions that are owned by the higher-level, more stable module, so that volatile implementation details depend on stable policy rather than the reverse.

9.3 The problem it solves

class MySQLDatabase:
    def save(self, record):
        print(f"INSERT INTO users ... {record}")


class UserService:
    """
    High-level policy: what it means to register a user.

    The constructor hard-codes a specific storage technology, which
    produces three separate defects examined below.
    """

    def __init__(self):
        self.database = MySQLDatabase()      # The defect is on this line

    def register(self, name, email):
        if "@" not in email:
            raise ValueError("Invalid email address")
        self.database.save({"name": name, "email": email})

The structural statement of the problem is that the arrow points in the wrong direction. Business policy is the stable, valuable part of a system and typically outlives several generations of storage technology. Storage is volatile. A dependency from stable to volatile means the stable component is destabilised by every change to the volatile one.

9.4 Resolution

An abstraction is introduced, defined in the vocabulary of the domain, and every concrete mechanism conforms to it.

from abc import ABC, abstractmethod


class UserRepository(ABC):
    """
    The abstraction, expressed entirely in domain vocabulary. There is no
    mention of tables, connections, queries, or files, which is what allows
    a relational store, a document store, an in-memory structure, or a
    remote service to implement it without distortion.

    Ownership note: conceptually this interface belongs to the business
    layer, not to the persistence layer, because it exists to state what
    the business layer requires. Placing it in the persistence package
    would satisfy the letter of the principle while defeating its purpose.
    """

    @abstractmethod
    def save(self, user: dict) -> None:
        ...

    @abstractmethod
    def find_by_email(self, email: str) -> dict | None:
        ...


class MySQLUserRepository(UserRepository):
    def save(self, user):
        print(f"MySQL insert: {user}")

    def find_by_email(self, email):
        print(f"MySQL select where email = {email}")
        return None


class InMemoryUserRepository(UserRepository):
    """
    A production-quality implementation for tests, not a mock. It has real
    behaviour and can therefore verify that the service actually stored
    what it claimed to store, which a bare mock cannot do without
    replicating the assertion logic in every test.
    """

    def __init__(self):
        self._users = {}

    def save(self, user):
        self._users[user["email"]] = user

    def find_by_email(self, email):
        return self._users.get(email)


class UserService:
    def __init__(self, repository: UserRepository):
        # The dependency arrives from outside. This class now names no
        # storage technology anywhere in its source, so no change of
        # storage technology can require editing it.
        self.repository = repository

    def register(self, name, email):
        if "@" not in email:
            raise ValueError("Invalid email address")
        if self.repository.find_by_email(email) is not None:
            raise ValueError("Email is already registered")
        self.repository.save({"name": name, "email": email})

Testing the business rule now requires no infrastructure whatsoever.

def test_duplicate_registration_is_rejected():
    repository = InMemoryUserRepository()
    service = UserService(repository)

    service.register("Ananya", "ananya@example.com")

    try:
        service.register("Ananya Again", "ananya@example.com")
        assert False, "Expected a duplicate registration to be rejected"
    except ValueError:
        pass

The test executes in microseconds, has no external dependency, and fails only when the business rule is wrong. This improvement in testability is the most immediately measurable benefit of DIP and is usually the argument that persuades teams to adopt it.

9.5 Why the relationship is called an inversion

Before applying the principle, the source-level dependency runs downward:

UserService  ---->  MySQLDatabase
 (policy)            (mechanism)

After applying it, the dependency from the mechanism has been reversed:

UserService  ---->  UserRepository  <----  MySQLUserRepository
 (policy)            (abstraction)          (mechanism)

Two properties of the second diagram deserve attention. First, the arrow from MySQLUserRepository points upward, which is the inversion the principle is named for. Second, UserService and UserRepository together form a self-contained unit that compiles, imports, and tests without any knowledge that MySQLUserRepository exists. That unit is the reusable, valuable core of the system.

The runtime call still flows from UserService into MySQLUserRepository. Only the source-level dependency has been inverted. Distinguishing the direction of control flow from the direction of source dependency is the conceptual key to the principle, and confusing the two is the most common source of misunderstanding.

9.6 Where the abstraction should live

Clause B of the formal statement has a structural consequence that is frequently ignored. An interface placed in the same package as its implementation, and shaped around that implementation’s capabilities, provides syntactic indirection without reducing coupling.

The practical test is to ask whether the business package can be packaged and shipped with its persistence package deleted. If it can, the inversion is real.

9.7 Dependency injection: the technique that realises DIP

Definition (dependency injection). The practice of supplying a module’s collaborators from outside the module rather than having the module construct or locate them itself.

Dependency inversion is the principle, which describes what the dependency structure should look like. Dependency injection is a technique, which describes how the correct structure is achieved at runtime. A third term, inversion of control, is broader still.

Three injection styles are in common use.

Constructor injection, which is the default choice.

class ReportService:
    def __init__(self, repository: UserRepository, formatter):
        # Required collaborators are supplied at construction, so an
        # instance cannot exist in a partially configured state. This is
        # the reason constructor injection is preferred by default.
        self.repository = repository
        self.formatter = formatter

Setter injection, for optional or replaceable collaborators.

class ReportService:
    def __init__(self, repository: UserRepository):
        self.repository = repository
        self._logger = NullLogger()      # Safe default, so the object is always usable

    def set_logger(self, logger):
        # Optional collaborator. Using setter injection here signals that
        # logging is not required for correct operation, which constructor
        # injection would have obscured by making it mandatory.
        self._logger = logger

Method injection, when the collaborator varies per call rather than per object.

class Checkout:
    def final_price(self, amount: float, policy: DiscountPolicy) -> float:
        # The policy differs for every customer, so binding it to the
        # object would force a new Checkout instance per customer.
        return amount - policy.discount_for(amount)

Framework-based injection delegates the wiring to a container, as with FastAPI’s Depends or the various dependency injection libraries. The benefit is reduced boilerplate in large applications; the cost is that the object graph is assembled by machinery that is harder to trace than explicit construction.

Regardless of style, the concrete implementations must be selected somewhere. That location is called the composition root, and it is conventionally the application’s entry point.

def main():
    """
    The composition root. This is the only function in the application that
    names concrete infrastructure classes. Every other module refers to
    abstractions, which is what makes the rest of the system portable.
    """
    repository = MySQLUserRepository()
    service = UserService(repository)
    service.register("Ananya", "ananya@example.com")

9.8 Architectural consequences

DIP applied consistently across a whole system produces a recognisable architecture. Business rules occupy the centre and depend on nothing external. Interfaces for everything the business rules require, such as persistence, messaging, and time, are defined in the centre. All infrastructure sits at the periphery and depends inward by implementing those interfaces.

This arrangement appears in the literature under several names: hexagonal architecture, ports and adapters, onion architecture, and clean architecture. They differ in terminology and in how many layers they name, but each is fundamentally an application of the Dependency Inversion Principle at the scale of an entire system. The interfaces defined by the centre are the ports; the infrastructure implementations are the adapters.

9.9 Costs and limits

Not every dependency should be inverted. The criterion is volatility combined with the need to substitute. Stable dependencies with no realistic alternative implementation should be used directly.

Indirection increases the cost of comprehension. Following a call from policy to the executing code requires knowing which implementation was wired at the composition root. In a large object graph this is genuine friction, and it is the reason explicit composition roots are preferable to magical container configuration in codebases of moderate size.

Abstractions defined too early are usually wrong. An interface extracted from a single implementation before a second one exists tends to reproduce the first implementation’s shape and then requires reworking when the second arrives. Extracting the interface at the moment the second implementation is genuinely needed produces a better abstraction with less rework.

9.10 Detection heuristics

9.11 Checkpoint questions

Q1. A team introduces an interface IUserRepository whose only method is execute_sql(query: str). Has DIP been satisfied?

Q2. Is datetime.now() a DIP violation?

Q3. Does dependency injection by itself guarantee dependency inversion?

10. How the Five Principles Interact

10.1 The principles are not independent

Presenting SOLID as five separate rules obscures the fact that they describe one structural property from five angles. Each principle, correctly applied, makes the others easier to satisfy, and each violation makes the others harder.

The causal chain runs as follows. Separating responsibilities produces classes with narrow purposes (SRP). Classes with narrow purposes naturally expose narrow interfaces, because there is little to expose (ISP). Narrow interfaces are easy for a subtype to honour completely, since the number of guarantees is small (LSP). When subtypes reliably honour their contracts, depending on an abstraction becomes safe rather than speculative (DIP). When clients depend on trustworthy abstractions, new behaviour can be introduced by adding implementations rather than editing existing code (OCP). Systems that are extended by addition accumulate less entanglement, which makes the next round of responsibility separation cheaper (SRP again).

The reverse chain is equally mechanical and describes how codebases decay. A class that accumulates responsibilities (SRP violation) exposes a wide interface (ISP violation). A wide interface cannot be fully honoured by every implementation, so implementations begin stubbing methods (LSP violation). Clients learn that the abstraction is unreliable and start checking concrete types to compensate (DIP violation). Type checks are conditionals on type, so each new variant requires editing them (OCP violation). At that point all five have failed, and the original cause was a single class that was allowed to grow.

10.2 Dependency map

10.3 Grouping by purpose

A different organisation of the same material is useful when deciding which principle to reach for.

LSP occupies a distinct position among the five. The other four describe how to structure code; LSP describes a correctness condition that the structure must satisfy for the others to deliver their benefits. An OCP design built on subtypes that violate their contracts is not extensible, it is merely indirect.

11. Capstone: Refactoring an Order Processing System

This section applies all five principles to a single realistic module. The starting point is code of a kind that appears in most codebases that have grown without periodic restructuring. The refactoring proceeds in explicit stages, and each stage states which principle motivates it and what would go wrong if the stage were skipped.

11.1 The starting point

class OrderManager:
    """
    Handles the complete order lifecycle. The word 'complete' in that
    sentence is the entire problem.
    """

    def __init__(self):
        self.orders = []

    def place_order(self, customer_type, items, payment_method, email):
        # Responsibility 1: pricing arithmetic
        total = sum(price * quantity for _, price, quantity in items)

        # Responsibility 2: discount policy, owned by the commercial team
        if customer_type == "regular":
            total *= 0.95
        elif customer_type == "premium":
            total *= 0.90
        elif customer_type == "vip":
            total *= 0.80

        # Responsibility 3: payment execution, owned by the payments team
        if payment_method == "card":
            print(f"Charging {total} to card via the card gateway")
        elif payment_method == "upi":
            print(f"Collecting {total} via UPI")
        elif payment_method == "cash":
            print(f"Recording {total} as cash on delivery")

        # Responsibility 4: persistence, owned by the platform team
        print("Executing INSERT INTO orders ...")

        # Responsibility 5: customer communication, owned by the growth team
        print(f"Sending confirmation email to {email}")

        order = {"items": items, "total": total}
        self.orders.append(order)
        return total

11.2 Diagnosis against all five principles

The order in which these are addressed matters. Extracting responsibilities (SRP) is performed first, because it produces the units against which the remaining principles are then applied. Attempting OCP or DIP inside a class that still does five things produces abstractions along the wrong boundaries.

11.3 Stage 1, separate responsibilities (SRP)

Each responsibility identified in the diagnosis becomes its own concept. At this stage the classes remain concrete; abstraction is introduced deliberately in later stages, only where an axis of change justifies it.

class OrderLine:
    """
    A value object representing one line of an order.

    Introduced because tuples of (name, price, quantity) carry no meaning
    at the point of use, permit silent argument reordering, and cannot
    enforce their own invariants.
    """

    def __init__(self, product_name: str, unit_price: float, quantity: int):
        if unit_price < 0:
            raise ValueError("Unit price cannot be negative")
        if quantity <= 0:
            raise ValueError("Quantity must be positive")

        self.product_name = product_name
        self.unit_price = unit_price
        self.quantity = quantity

    @property
    def line_total(self) -> float:
        # Behaviour placed on the data it operates on, which avoids the
        # anaemic model problem discussed in Section 5.8.
        return self.unit_price * self.quantity


class Order:
    """
    The order entity. It owns its own invariants and nothing else. It does
    not know how it is priced, paid for, stored, or announced.
    """

    def __init__(self, customer_email: str):
        self.customer_email = customer_email
        self.lines: list[OrderLine] = []
        self.total: float | None = None

    def add_line(self, line: OrderLine) -> None:
        self.lines.append(line)

    @property
    def subtotal(self) -> float:
        return sum(line.line_total for line in self.lines)

11.4 Stage 2, make the varying policies extensible (OCP)

The two conditionals identified in the diagnosis are replaced by abstractions, because both branch on sets that are known to grow.

from abc import ABC, abstractmethod


class DiscountPolicy(ABC):
    """
    Axis of change: the commercial team introduces new customer tiers and
    promotional schemes several times a year. This is the clearest possible
    justification for an abstraction, since the axis is demonstrated rather
    than predicted.
    """

    @abstractmethod
    def discount_for(self, subtotal: float) -> float:
        """Return the absolute discount amount, never the discounted total."""
        ...


class NoDiscount(DiscountPolicy):
    def discount_for(self, subtotal): return 0.0


class RegularDiscount(DiscountPolicy):
    def discount_for(self, subtotal): return subtotal * 0.05


class PremiumDiscount(DiscountPolicy):
    def discount_for(self, subtotal): return subtotal * 0.10


class VIPDiscount(DiscountPolicy):
    def discount_for(self, subtotal): return subtotal * 0.20


class CappedDiscount(DiscountPolicy):
    """
    A composite policy that wraps another and limits its effect.

    Its existence is the strongest evidence that a class-based abstraction
    was the right choice over a dictionary of percentage rates: this
    variant expresses behaviour that no table of constants could represent,
    and it was added without modifying any existing policy.
    """

    def __init__(self, inner: DiscountPolicy, maximum: float):
        self.inner = inner
        self.maximum = maximum

    def discount_for(self, subtotal):
        return min(self.inner.discount_for(subtotal), self.maximum)

11.5 Stage 3, invert the infrastructure dependencies (DIP and ISP)

Payment, persistence, and notification are all mechanisms behind stable policy. Each receives an abstraction expressed in domain vocabulary, and each abstraction is deliberately narrow so that no client depends on operations it does not use.

class PaymentGateway(ABC):
    """
    One method, because the order workflow requires exactly one operation.
    Refunds and settlement reports are genuine capabilities but belong to
    separate interfaces used by separate clients, in accordance with ISP.
    """

    @abstractmethod
    def charge(self, amount: float, reference: str) -> bool:
        """Return True when the charge succeeds, False when it is declined."""
        ...


class OrderRepository(ABC):
    @abstractmethod
    def save(self, order: Order) -> None: ...


class OrderNotifier(ABC):
    @abstractmethod
    def notify_confirmed(self, order: Order) -> None: ...


class CardGateway(PaymentGateway):
    def charge(self, amount, reference):
        print(f"Card charge of {amount} for {reference}")
        return True


class UPIGateway(PaymentGateway):
    def charge(self, amount, reference):
        print(f"UPI collection of {amount} for {reference}")
        return True


class CashOnDeliveryGateway(PaymentGateway):
    """
    Honours the contract without moving money at authorisation time.

    LSP check: the contract states that True means the charge succeeded,
    where success is defined as the payment being validly arranged. Cash on
    delivery arranges payment at delivery, which satisfies that definition.
    Had the contract stated that True means funds have settled, this class
    would violate it and would require a different abstraction.
    """

    def charge(self, amount, reference):
        print(f"Cash on delivery recorded: {amount} for {reference}")
        return True


class SQLOrderRepository(OrderRepository):
    def save(self, order):
        print(f"Persisting order for {order.customer_email}")


class InMemoryOrderRepository(OrderRepository):
    def __init__(self):
        self.saved: list[Order] = []

    def save(self, order):
        self.saved.append(order)


class EmailNotifier(OrderNotifier):
    def notify_confirmed(self, order):
        print(f"Confirmation email to {order.customer_email}")


class NullNotifier(OrderNotifier):
    """Used in tests and batch imports where no customer contact is desired."""

    def notify_confirmed(self, order):
        pass

11.6 Stage 4, the orchestrator

The remaining class coordinates the workflow and does nothing else. Its single reason to change is a change to the sequence or composition of steps in placing an order.

class PaymentDeclined(Exception):
    """
    A domain-level exception. The service raises this rather than a
    gateway-specific error, so callers never need to know which gateway
    was used. Leaking a gateway exception here would reintroduce the
    dependency that the PaymentGateway abstraction removed.
    """


class OrderService:
    def __init__(
        self,
        discount_policy: DiscountPolicy,
        payment_gateway: PaymentGateway,
        repository: OrderRepository,
        notifier: OrderNotifier,
    ):
        self.discount_policy = discount_policy
        self.payment_gateway = payment_gateway
        self.repository = repository
        self.notifier = notifier

    def place_order(self, order: Order) -> float:
        subtotal = order.subtotal
        discount = self.discount_policy.discount_for(subtotal)
        order.total = subtotal - discount

        # Payment precedes persistence so that a declined payment leaves no
        # order record. The alternative ordering, persisting first and
        # marking the order failed afterwards, is also defensible and is
        # chosen when an audit trail of failed attempts is required. The
        # decision belongs here, in the workflow, which is exactly why the
        # workflow is a responsibility in its own right.
        if not self.payment_gateway.charge(order.total, order.customer_email):
            raise PaymentDeclined(f"Payment declined for {order.customer_email}")

        self.repository.save(order)
        self.notifier.notify_confirmed(order)
        return order.total

11.7 Composition and testing

def main():
    """The composition root, and the only place concrete classes are named."""
    order = Order("ananya@example.com")
    order.add_line(OrderLine("Textbook", 1200.0, 2))
    order.add_line(OrderLine("Notebook", 80.0, 5))

    service = OrderService(
        discount_policy=CappedDiscount(VIPDiscount(), maximum=500.0),
        payment_gateway=UPIGateway(),
        repository=SQLOrderRepository(),
        notifier=EmailNotifier(),
    )
    service.place_order(order)


def test_discount_is_applied_and_order_is_persisted():
    """
    A complete test of the ordering workflow with no infrastructure. This
    is the practical payoff of the refactoring and would have been
    impossible against the original OrderManager.
    """

    class DecliningGateway(PaymentGateway):
        def charge(self, amount, reference):
            return False

    repository = InMemoryOrderRepository()
    order = Order("test@example.com")
    order.add_line(OrderLine("Book", 1000.0, 1))

    service = OrderService(
        discount_policy=RegularDiscount(),
        payment_gateway=DecliningGateway(),
        repository=repository,
        notifier=NullNotifier(),
    )

    try:
        service.place_order(order)
        assert False, "A declined payment should prevent order placement"
    except PaymentDeclined:
        pass

    assert repository.saved == [], "No order should be persisted after a decline"

11.8 Verification against each principle

11.9 An honest accounting of the cost

The original implementation was one class of roughly thirty lines. The refactored version is thirteen classes across roughly a hundred and fifty lines. That expansion is a real cost and must be justified rather than assumed.

The justification rests on specific, observed facts about this domain: customer tiers change several times a year, payment methods are added when the business enters new markets, and the ordering workflow must be tested without infrastructure because it encodes revenue-critical rules. Each abstraction in the final design corresponds to one of those documented axes of change.

Had the business supported exactly one customer tier and one payment method with no expectation of growth, the original class would have been the better design, and the refactoring would have been speculative generality. The engineering judgement is not “apply SOLID” but “identify the axes along which this system will actually change, and pay for abstraction only along those axes.”

12. SOLID Beyond Classes: Functions, Modules, and Services

The principles are usually taught with classes because that is the granularity at which they are easiest to demonstrate. They apply unchanged at every level of decomposition, and recognising this generalisation is a mark of maturity in applying them.

Two entries in this table deserve elaboration.

Stamp coupling at function level. A function that accepts an entire Order object in order to read order.total is coupled to the whole of Order. Accepting total: float removes that coupling, makes the function reusable in contexts that have no Order, and states the actual requirement in the signature. This is ISP applied to a parameter list.

The shared database as a DIP violation between services. When two services read and write the same tables, each is coupled to the other’s internal storage schema, which is the most concrete detail either service has. Neither can change its schema independently, so the services are separately deployable but not separately modifiable, which forfeits the main benefit of separating them. Communicating through published contracts restores the inversion.

13. Anti-Patterns and Misapplications

The failures below are all committed by developers who have learned SOLID and are applying it earnestly. They are more common in practice than outright ignorance of the principles.

13.1 Speculative generality

An abstraction is created for a variation that has never occurred and has not been requested. The codebase carries an interface, a factory, and a configuration entry to support exactly one implementation.

The diagnostic is quantitative: count the implementations of each abstraction in the codebase. An abstraction with a single implementation and no documented plan for a second is a candidate for removal. The counter-consideration is testability, since an abstraction with one production implementation and one test implementation genuinely has two, and that is sufficient justification when the dependency is infrastructural.

13.2 Mechanical splitting mistaken for SRP

A large class is divided by line count or by alphabetical grouping of methods rather than by reason to change. The result is two classes that must always be modified together, so the blast radius is unchanged while the comprehension cost has doubled. The corrective question is not “is this class large” but “which distinct actors can require this class to change.”

13.3 The anaemic domain model

Every behaviour is extracted into a service class, leaving entities as bare attribute containers. Invariants that the entity should enforce are enforced instead by whichever service remembers to check them, which means they are eventually enforced inconsistently. Behaviour that maintains an entity’s own invariants belongs on the entity; behaviour that coordinates several entities or reaches outside the process does not.

13.4 Interface proliferation

Every class is given a corresponding interface, frequently generated mechanically and named by prefixing the class name. These are header interfaces in the sense of Section 8.7: they mirror an implementation rather than describing a client’s role, so they add a file and an indirection without reducing coupling.

13.5 Abstraction in the wrong vocabulary

An interface is introduced, satisfying clause A of DIP, but its methods are named after the implementation’s operations, violating clause B. IEmailSender.send_smtp_message is abstract in form and concrete in meaning. The test is whether a genuinely different implementation could satisfy the interface without distortion.

13.6 Configuration-driven complexity

Extensibility is pursued through configuration files and runtime registries in a system where the set of variants is small, internal, and stable. The result is behaviour that cannot be traced by reading code, that fails at runtime rather than at import time, and that requires reading two artefacts to understand one flow. Registries are appropriate for genuine plugin systems and are overhead for five internal variants.

13.7 Applying principles without measuring the outcome

The strongest available evidence for whether a design decision worked is the version control history. If a class was split six months ago and both halves have changed together in every subsequent commit, the split was wrong and should be reversed. Design principles produce predictions about future change; the repository records what actually happened, and consulting it converts design from an aesthetic exercise into an empirical one.

14. When SOLID Should Not Be Applied

Each principle imposes a cost in indirection, file count, and comprehension effort. That cost is justified only when the corresponding benefit is realised, and the benefit is realised only when the code changes in the anticipated way.

Two general guidelines summarise the judgement required.

The rule of three. Write the direct implementation for the first case. Duplicate or extend it for the second while observing what actually varies. Introduce the abstraction at the third, when the axis of change has been demonstrated by evidence rather than predicted. This sequence produces better abstractions than up-front design, because it is informed by real variation.

Abstract the boundaries, keep the core concrete. Apply DIP aggressively where the system meets databases, networks, clocks, file systems, and third-party services, because these are volatile and make testing expensive. Keep pure domain computation concrete, direct, and free of indirection, because it is stable, deterministic, and already easy to test.

15. Summary and Key Takeaways

15.1 Principle reference

15.2 Diagnostic quick reference

15.3 Key takeaways

1. The principles share a single objective, which is reducing the cost of change. Each addresses a different mechanism by which change becomes expensive, and every one of them can be restated as an instruction to lower coupling or raise cohesion.

2. The principles form a reinforcing system rather than a checklist. Correct application of one makes the others easier to satisfy, and a violation of one propagates predictably into violations of the rest, beginning almost always with an unchecked accumulation of responsibilities.

3. Contracts are behavioural, not syntactic. A subclass that matches every signature and violates a single guarantee has broken the abstraction as thoroughly as one that fails to compile. This is the reason LSP occupies a different position from the other four.

4. Abstraction is a bet on a predicted axis of change. Correct predictions repay their cost at the first variation; incorrect predictions impose permanent indirection that serves nothing. Deferring abstraction until the axis is demonstrated by evidence produces better designs than predicting it in advance.

5. Testability is the most reliable available proxy for good design. Code that can be unit tested without infrastructure has, almost by construction, separated policy from mechanism, depends on abstractions, and has narrow interfaces. When a design decision is genuinely unclear, asking how the result will be tested resolves it more often than any other question.

6. The most common failure among practitioners is over-application, not under-application. Speculative abstraction, mechanical splitting, and interface proliferation are the characteristic errors of developers who have recently learned SOLID, and they are more expensive than the entangled code they were intended to prevent.

7. SOLID is the conceptual foundation of the design patterns catalogue. Nearly every pattern in the Gang of Four catalogue is a concrete, named realisation of one or more of these principles, which is why the patterns become substantially easier to understand once the principles are secure.

16. Self-Assessment Questions with Answers

Answer each question in writing before expanding the response. Questions test conceptual discrimination rather than recall, and several are deliberately constructed so that the obvious answer is incorrect.

Q1. A Report class has eighteen methods, all operating on the same dataset and all changing whenever the reporting requirements change. Does it violate SRP?

Q2. Is it possible to satisfy SRP fully while violating OCP badly?

Q3. A subclass overrides a method to add caching. Under what circumstances is this an LSP violation?

Q4. Explain the difference between the Dependency Inversion Principle and dependency injection, and state whether either implies the other.

Q5. An interface declares save, load, delete, export_to_csv, and send_by_email. Which principle is most clearly violated, and what is the secondary consequence?

Q6. Under what circumstances should a conditional chain be preferred over polymorphic dispatch?

Q7. A team introduces IUserService, IOrderService, and IPaymentService, each with exactly one implementation and each mirroring its implementation’s full public surface. Evaluate this design.

Q8. Two classes have been separate for a year. Version control shows they have been modified in the same commit on every occasion. What does this indicate?

Q9. Why is the Liskov Substitution Principle described as occupying a different position from the other four?

Q10. A senior engineer rejects a pull request that introduces four new interfaces to support a single feature. What questions should the reviewer be asking?

17. Practice Exercises with Solutions

Attempt each exercise before reading the solution. Solutions include the reasoning behind the design choices, not only the resulting code, because the reasoning is the transferable part.

Exercise 1: Diagnose and repair an SRP violation

Identify every responsibility in the class below, name the actor associated with each, and restructure accordingly.

class Invoice:
    def __init__(self, items):
        self.items = items                       # list of (name, price, quantity)

    def calculate_total(self):
        return sum(price * quantity for _, price, quantity in self.items)

    def calculate_tax(self):
        return self.calculate_total() * 0.18

    def save_to_pdf(self, filepath):
        print(f"Writing PDF to {filepath}")

    def send_by_email(self, recipient):
        print(f"Emailing invoice to {recipient}")

    def record_in_ledger(self):
        print("INSERT INTO ledger ...")

class InvoiceLine:
    def __init__(self, description: str, unit_price: float, quantity: int):
        self.description = description
        self.unit_price = unit_price
        self.quantity = quantity

    @property
    def line_total(self) -> float:
        return self.unit_price * self.quantity


class Invoice:
    """
    Holds invoice state and computes only what is intrinsic to it. The
    subtotal is intrinsic, because it is a direct consequence of the lines
    present. Tax is not intrinsic, because it depends on jurisdiction and
    on rules owned outside the invoice.
    """

    def __init__(self, lines: list[InvoiceLine]):
        self.lines = lines

    @property
    def subtotal(self) -> float:
        return sum(line.line_total for line in self.lines)


class TaxCalculator:
    """
    Owned by Finance. Made a class rather than a constant so that
    jurisdiction-specific subclasses or configured rates can be introduced
    later without changing any caller.
    """

    def __init__(self, rate: float = 0.18):
        self.rate = rate

    def tax_for(self, invoice: Invoice) -> float:
        return invoice.subtotal * self.rate


class InvoicePdfRenderer:
    def render(self, invoice: Invoice, tax: float, filepath: str) -> None:
        # Receives the computed tax rather than a TaxCalculator, so that it
        # cannot recompute or reinterpret monetary values. This keeps the
        # two responsibilities from silently merging again.
        print(f"PDF at {filepath}: subtotal {invoice.subtotal}, tax {tax}")


class InvoiceEmailSender:
    def send(self, recipient: str, filepath: str) -> None:
        print(f"Emailing {filepath} to {recipient}")


class LedgerRepository:
    def record(self, invoice: Invoice, tax: float) -> None:
        print(f"Recording {invoice.subtotal + tax} in the ledger")