This is the second lecture of Chapter 5. Lecture 1 described the detailed design process; this one is about the principles that make a detailed design good: easy to change, reuse and test.

Internal structure means which classes and interfaces a component contains and how they relate. It is drawn with class diagrams.

SOLID is five principles. Only the first three (S, O, L) are taught in this lecture; slide 39 moves I and D to the next one.

Internal behavior (what the classes do at run time, drawn with sequence or state diagrams) is also left for the next lecture.

Component design is the part of detailed design that opens each component up. Structure is what it is made of (classes, attributes, interfaces); behavior is how those parts act to deliver the component’s services.

It does not invent new top-level components. It refines the ones the architect already chose, so every class you design belongs to one architectural component.

In an object-oriented system each component’s inside is usually shown with one or more class diagrams. A large component may need several.

How to read the top diagram (architecture view):

ClientSystem, ServerSystem

UML components: boxes with the small component icon. They are black boxes at this stage.

Ball-and-socket on ServerInterface

The circle (ball) is the interface ServerSystem provides; the half-circle (socket) is what ClientSystem requires. Joined, they mean the client uses that service.

The bottom diagram is the same two components after detailed design: they are opened up to show the classes inside.

Client

A class inside ClientSystem.

«interface» ServerInterface

The provided interface, now an actual interface type inside ServerSystem.

The dashed arrow with an open arrowhead from Client to ServerInterface is a dependency: Client calls the interface and never names the concrete class.

The dashed line with a hollow triangle from ConcreteServer to ServerInterface is realization: ConcreteServer implements the interface. Another class could replace it and Client would not change.

The takeaway box says it in one line: in detailed design you stop thinking in components and start thinking in classes, interfaces and types.

Four things are decided in component design. Data structures say how information is stored. Algorithms say how results are computed. Interface details are the exact method names, parameters and return types. Communication mechanisms say how components talk: direct calls, messages or events.

That makes component design the place where functional correctness is won or lost. Architecture can be perfect, but if the algorithm or the data passed between classes is wrong, the system still gives wrong answers.

In the payment example the three classes must agree on details like the order of operations (discount before tax?) and the number format. Only then is the total right for every valid input. Those agreements are exactly what component design writes down.

Because component design fixes the actual logic, it is a major factor in whether the system does what users need.

The four object-oriented ideas a component designer must be fluent in. Slides 7–14 refresh each one:

Class / object

A class is the blueprint; an object is one instance created from it at run time.

Abstract class / interface

Types that define a contract other classes must complete or implement.

Inheritance

A subclass reuses and specializes a parent (“is-a”).

Polymorphism

One call, such as animal.sound(), runs different code depending on the actual object.

An abstract class is declared with the abstract keyword. It can mix abstract methods (a signature with no body) and concrete methods (normal methods with code). The slide’s definition requires at least one abstract method. Java itself also accepts an abstract class with none, but answer with the slide’s definition in the exam.

Any concrete (non-abstract) subclass must give a body to every abstract method it inherits. If it doesn’t, it must be declared abstract too.

“Cannot be instantiated” means new Animal() is a compile error when Animal is abstract. You can still declare a variable of that type: Animal a = new Cat();.

The four reasons all come down to sharing: common code lives once in the parent (default functionality, reuse), and the abstract methods fix a common set of operations every subclass must offer (template, common interface).

Reading the small diagram:

Top box «abstract»

The abstract class. It holds an abstract method (italic) and + concreteMethod(), which has a body.

Arrow to ConcreteClass

ConcreteClass derives from it and supplies + abstractMethod(). The slide draws the arrow downward; standard UML points a hollow triangle from the subclass up to the parent.

An interface is a pure contract: it lists method signatures and no code. The slide says no concrete methods at all. Modern Java also allows default and static methods, but for this course an interface has only abstract methods.

You cannot write new AnimalInterface(). You create an object of a class that implements it and refer to it through the interface type.

Interfaces hold no instance variables (no per-object state). The only fields allowed are constants: public static final.

Benefits: loose coupling, because callers depend on the contract and not on a specific class. Dynamic method resolution: at run time Java runs the method of the actual object behind the interface. It also lets unrelated classes share a capability outside one inheritance tree, since a Java class can implement many interfaces but extend only one class.

Further reading on when to choose an interface or an abstract class in Java.

Further reading on UML relationships. The #4 anchor jumps to the section on generalization and realization, the two arrows used on slides 10–12.

The code, line by line:

Watch the mismatch: the interface asks for drawe(), but Cat provides eat(). As printed, Java would reject Cat (“does not override abstract method drawe()”). The UML on the right shows what was intended: the interface has sound() and eat().

Reading the UML:

«interface» Animal

The stereotype in guillemets marks the box as an interface.

Horse, Cat

Classes that each provide + sound() and + eat().

Dashed lines with a hollow triangle

Realization: the triangle points at the interface each class implements.

The code, line by line:

In UML, italics carry meaning: the class name Animal in italics means abstract class, and sound() in italics means abstract operation. eat() is upright because it has a body.

Notation trap: the slide calls the dashed arrows “Realization”. Standard UML uses realization (dashed line, hollow triangle) for implementing an interface, and generalization (solid line, hollow triangle) for extending a class, abstract or not. In an exam, draw extends with a solid line and say why.

Here Animal is an ordinary (concrete) class, so every method already has a body:

Unlike slide 11, nothing forces the subclasses to override: they could inherit Animal’s versions unchanged. Overriding is a choice here, not a requirement.

The UML shows generalization: solid lines meeting at one hollow triangle that points at the parent, Animal. Read it as “Horse is an Animal” and “Cat is an Animal”.

The demo creates one object of each class and calls both methods:

The output panel on the right confirms each object runs the version defined in its own class. Every variable here has the same type as its object, so this is plain inheritance. Slide 14 shows what changes when the types differ.

The variables are declared as Animal but hold a Horse and a Cat:

This is polymorphism (dynamic binding). The declared type (Animal) decides which methods you are allowed to call; the actual object (Horse or Cat) decides which code runs. The choice happens at run time.

Why it matters for this lecture: OCP (slides 22–31) works because a GameEngine holding a Character reference can call move() and get each character’s own movement without knowing its class.

The goal of every principle that follows: designs that are less complex, reusable, easier to modify and easier to maintain.

SOLID is the acronym for the five principles: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. S, O and L are covered in this lecture.

The common misreading: “every module should do just one thing.” That is good advice for small functions, but it is not what SRP says.

SRP is about who causes change. A module should answer to one actor (a user group, stakeholder or policy). Equivalently, a class has one reason to change. If the accountants and the IT team could each force edits to the same class, it has two responsibilities.

The code (TypeScript-style), line by line:

The boxed lines show the violation: Person now has two reasons to change. Its fields change when what a person is changes; validateEmail changes when the email rules change (new domains, longer TLDs). You also can’t test the email rule without building a Person.

The refactoring moves validation into its own class:

Each class now has one reason to change: email-rule changes touch only Email, and person changes touch only Person. A class with one responsibility (one actor) is also easier to read, test and extend.

The violating Employee class stores data, calculates taxes and prints pay stubs. Three different things can force edits: the data structure, the tax laws and the print format.

The SRP version keeps only the employee data in Employee. Tax calculation and pay-stub printing move to their own classes, so Employee changes only when the data changes.

The slide’s question has a clear answer, given on slide 20: no. SRP does not mean one class per function.

A responsibility is usually carried out by several related methods working together. SRP limits the number of responsibilities, not the number of methods.

ReportGenerator mixes three responsibilities: calculation (calculateTax), formatting (printToPDF) and communication (sendEmail). Each changes for a different reason.

TaxCalculator has three methods but one responsibility, tax calculation. The table adds two more good examples: UserAuthentication (login state, four methods) and ProductValidator (product data correctness, three methods).

The test for splitting: if you change method A, would you also have to change method B? If yes, they belong together (both tax methods change with tax law). If no, they belong in separate classes (calculateTax and printToPDF).

Three requirements means three potential reasons to change: pay rules, storage technology and report format.

Question 1, a design that violates SRP (one class does everything):

Employee
  - id, name, baseSalary
  + calculateSalary(): double
  + saveToDatabase(): void
  + generateReport(): String

Question 2, the SRP redesign. Employee keeps the data; each job gets its own class, and each one depends on (uses) Employee:

Employee
  - id, name, baseSalary          (data only)

SalaryCalculator
  + calculateSalary(e: Employee): double
EmployeeRepository
  + save(e: Employee): void
EmployeeReportGenerator
  + generate(e: Employee): String

all three  - - ->  Employee    (dependency)

OCP is what lets a system keep growing for years without every new feature breaking old ones.

“Open to extension” means you can add new behavior. “Closed for modification” means code that already works and is tested stays as it is.

There is no contradiction: the system still changes, but by adding classes (a new subclass, a new implementation) that plug into existing abstractions. No working code has to be edited for that.

The scenario matters: several kinds of characters exist, and more will be added. A change is expected, so the design must be ready for it.

Reading the diagram:

GameEngine

Has one operation, add(pCharacter: TerrestrialCharacter*). The * is a C++ pointer.

Dashed arrow

A dependency: GameEngine uses TerrestrialCharacter directly.

TerrestrialCharacter

A concrete class with draw() and run().

Why it violates OCP: GameEngine names a concrete class. Every new kind of character (one that flies, one that swims) forces a change to GameEngine, the code that already works.

The C++ code, line by line:

add(...) is hard-wired to one concrete type and one way of moving (run).

An AerialCharacter that flies doesn’t fit: it isn’t a TerrestrialCharacter and has no run(). Supporting it means editing add(...), which is working code. That edit is the OCP violation.

The fix students should propose: introduce an abstraction (an interface or abstract class) named Character with the operations every character has, and make GameEngine depend on Character instead of on a concrete class. Slides 26–29 show how a first attempt still goes wrong, and then the correct version.

Joe’s first attempt (C++):

Joe abstracted the drawing, but movement was left to each subtype under different names (fly, run). Character itself has no movement operation.

The getType() method is the warning sign: a caller that has to ask “what type are you?” is about to branch on the answer. Slide 27 shows that branch.

GameEngine.add with Joe’s design:

Encapsulate variation: the part that changes (how each character moves) should be hidden behind one stable operation. Here it leaks into GameEngine as an if/else that “will always vary” with the set of characters.

It runs correctly, but it still violates OCP: adding an AquaticCharacter means editing add() again with another branch and another cast.

The fix: put one movement operation, move(), into Character itself (virtual void move() = 0). “How it moves” becomes each subtype’s private business.

Each subtype implements the full contract:

AerialCharacter

draw() draws it, move() makes it fly.

TerrestialCharacter (sic)

draw() draws it, move() makes it run.

Reading the new diagram (left) against the old one (right):

GameEngine - - -> «interface» Character

GameEngine depends only on the interface. The italic +draw() and +move() are abstract operations.

Aerial / Terrestrial / AquaticCharacter

Each realizes Character (dashed line, hollow triangle) and implements both operations.

Old design

GameEngine depended on the concrete TerrestrialCharacter.

AquaticCharacter is added by writing one new class. GameEngine, Character and the existing characters are not touched. That is OCP.

add() now just calls draw() and move(); polymorphism (slide 14) runs the right movement. The same design in Java:

interface Character {
    void draw();
    void move();
}
class AquaticCharacter implements Character {
    public void draw() { /* draw a fish */ }
    public void move() { /* swim */ }
}
class GameEngine {          // never changes
    void add(Character c) {
        c.draw();
        c.move();
    }
}

OCP is a direction, not an absolute. Something always has to be edited: a factory, a configuration or a list of characters.

The skill is to predict where change is likely (new character types, new salary types, new payment methods), hide that variation behind an abstraction, and let polymorphism pick the implementation.

The same rule restated for any software entity: a class, module or function.

Model answer: make the varying part (how a salary is computed) an interface, so a new salary type is a new class.

«interface» SalaryPolicy
  + calculate(e: Employee): double

MonthlySalary, HourlySalary, WeeklySalary
  - - -|>  SalaryPolicy        (realization)

SalaryCalculator               (never edited)
  + calculateSalary(e: Employee,
                    p: SalaryPolicy): double

New CommissionSalary = one new class
that implements SalaryPolicy.

The “implied contract” is everything callers rely on: the method names and types, but also the behavior (what the method promises to do and what it requires before it is called).

If code works with a parent object, it must keep working when you hand it a child object instead. The slide calls this the “treat alike” rule.

Two requirements: the method signatures stay compatible, and anything you could conclude from the parent’s specification must still hold for the subtype.

Signature rule: if a program type-checks against the parent’s methods, it type-checks with the child too (same methods with compatible parameters and return types). The compiler mostly enforces this.

Methods rule: reasoning about a call stays valid even though the child’s code runs. If move() promises “moves over land”, every override must still move over land. The compiler can’t check this, so the designer must.

The plain-language version: a child class must work anywhere the parent works, without anything breaking.

The code and its contract:

Answer: no, it violates LSP. It compiles (signature rule OK) but breaks the postcondition “roams over land”. Code that relies on terrestrial characters staying on the ground, such as collision with water or bridges, misbehaves when given this subclass.

The lesson in red: OCP alone isn’t enough. The class was added by extension (OCP satisfied), yet the design is wrong because the subtype isn’t substitutable. A similar trap is a subclass whose move() throws an exception (“Ghosts don’t move!”): that also breaks the contract.

The classic LSP violation. Mathematically every square is a rectangle, but in software Square should not inherit from Rectangle.

Rectangle’s implied contract: setH and setW change only their own dimension. A user that sets width 5 and height 2 expects an area of 10.

A Square has to keep its sides equal, so its setters change both. After setW(5); setH(2) the area is 4, not 10.

Diagram and fix:

User → Rectangle

Solid arrow: User is associated with and uses Rectangle (+setH, +setW).

Square → Rectangle (hollow triangle)

Generalization: Square inherits from Rectangle and adds +setSide.

Fix

Don’t inherit. Make Square and Rectangle siblings under a Shape abstraction that offers only what both can honor, e.g. area().

Reading the diagram:

Billing → License

Billing uses License and calls calcFee().

<I> License

An interface with one operation, + calcFee().

PersonalLicense, BusinessLicense

Implement License. BusinessLicense also keeps - users (a private field) because its fee depends on the number of users.

Each subtype computes the fee differently (a flat personal fee; a fee per business user), but both honor the contract “return this license’s fee”.

Billing’s behavior never depends on which subtype it receives, so both are substitutable: LSP holds. It is also OCP-compliant, because a new license type is a new class. In Java:

interface License { double calcFee(); }

class PersonalLicense implements License {
    public double calcFee() { return 100.0; }
}
class BusinessLicense implements License {
    private int users;
    public double calcFee() {
        return users * 50.0;
    }
}
class Billing {
    void printBill(License l) {
        System.out.println(l.calcFee());
    }
}

Use LSP to sanity-check every inheritance arrow you draw: ask whether the child can stand in for the parent everywhere.

Inheritance is about keeping expected behavior, not just reusing code. If the honest answer is “only sometimes”, use composition or a different abstraction instead.

Fruit promises two operations every fruit can do: Peel() and MakeSmoothie().

Orange: peeling and blending both work exactly as Fruit promises. LSP holds.

Coconut: you don’t peel a coconut like other fruit; you crack it open. If Coconut.Peel() throws an error or does something callers don’t expect, a program that peels any Fruit breaks. LSP is violated. Model drawing and fix:

Violation
  Fruit  (+Peel(), +MakeSmoothie())
    ^ Orange    both work
    ^ Coconut   Peel() fails

Fix
  «interface» Peelable   (+Peel())
  «interface» Blendable  (+MakeSmoothie())
  Orange  implements Peelable, Blendable
  Coconut implements Blendable
          and adds its own +Crack()

Covered so far: component design, the OO refresher, and S, O and L. The Interface Segregation and Dependency Inversion principles come in the next lecture.

Also next lecture: designing the internal behavior of components.