Third detailed-design lecture: the last two SOLID principles (I and D), then how to model a component’s behaviour and general rules of good design.

Already covered in Lecture 2: SRP, OCP and LSP.

This lecture: the Interface Segregation Principle and the Dependency Inversion Principle, completing SOLID.

Then designing internal behaviour and the rules of design.

The starting point is SRP: a well-designed class has one reason to change.

When that is violated, the interfaces the class offers usually provide more than they should, which makes designs harder to maintain and reuse.

The Interface Segregation Principle (ISP): classes (or methods) should not be forced to depend on methods they do not use.

The example: a game with enemy characters that roam over land, fly or swim, plus a super enemy that can do all three.

The tempting design: one EnemyCharacter with fly(), run() and swim(), inherited by Aerial, Terrestrial, Aquatic and SuperCharacter. The slide labels it a bloated interface.

The rule of thumb: many client-specific interfaces are better than one general-purpose interface.

Aerial, Terrestrial and Aquatic characters are polluted with methods they can’t perform: an aerial character inherits run() and swim(), a terrestrial one fly().

The design also violates LSP (Lecture 2): code holding an EnemyCharacter may call fly(), but a TerrestrialCharacter put in its place can’t fly, so it can’t safely substitute for its parent.

Only SuperCharacter conforms to the base type syntactically and semantically. It is the only class that really needs (and honours) all three methods, so it is the only one that satisfies LSP.

ISP: use small, specific interfaces instead of one big interface full of unused methods. Problem here: AerialCharacter and AquaticCharacter are forced to implement run(); the interface is polluted.

LSP: a subclass must replace its parent without breaking correctness. Problem here: a TerrestrialCharacter can’t replace an EnemyCharacter when the code expects fly().

In short: ISP → interfaces should be specific; LSP → subclasses must behave consistently with their base class. Fixing the interfaces (next slide) fixes both.

The ISP fix: three small interfaces, «interface» AerialCharacter (fly()), TerrestrialCharacter (run()) and AquaticCharacter (swim()). Each client class (dashed realization arrows) implements only the one it can honour.

«interface» SuperCharacter declares all three operations and is implemented by SuperCharacterClient. In the slide’s version the three small interfaces extend SuperCharacter (hollow triangles pointing down to it); conceptually it is the combination of the three capabilities.

The Extra box: Java rules about overriding when types are combined:

Abstract class implements an interface

No override needed: it can leave the methods abstract.

Abstract class extended by a concrete class

Yes: the concrete subclass must override every abstract method.

Normal class implements an interface

It must override all the interface’s abstract methods.

Interface extends interface

No override: interfaces only add declarations.

The code, top to bottom:

The intent: a reference of a narrow type can only request what that character can do, so unsupported calls become impossible. Exam answers should draw the small interfaces as independent, each implemented by the classes that need it.

Violation: one Worker interface with work() and eat().

Applied: split the interface by capability.

The Dependency Inversion Principle (DIP): the most flexible systems are those whose source-code dependencies refer only to abstractions, not to concretions.

In a statically typed language like Java, that means use, import and include statements should name only interfaces, abstract classes or other abstract declarations.

Nothing concrete should be depended on: concrete classes change often, abstractions rarely.

In particular, avoid depending on modules that are actively being developed and change frequently: every change there would ripple into your code.

The two rules. (1) High-level modules (policy, e.g. a Manager) must not depend on low-level modules (details, e.g. a Worker). Both depend on an abstraction (an interface).

(2) Abstractions must not depend on details; details depend on abstractions.

The diagram: without inversion, Object A in Package A references Object B in Package B directly. With inversion, Object A references Interface A, and Object B implements (inherits) Interface A. The arrow from B now points toward the abstraction, the opposite (“inverted”) direction of the original dependency.

The real-life idea: a charger that only works with Samsung phones is useless when you change phones (bad). A USB charger works with any phone (good): USB is the interface, the abstraction.

The same mistake in code, the charger that only fits one phone:

Switch without dependency inversion:

The problem: Switch works only with Fan. To control a Light you must change Switch.

The fix in three steps:

Passing the dependency in from outside (instead of new Fan() inside) is called dependency injection; it is the usual way to apply DIP.

The textbook bad example, line by line:

Manager is the high-level module and depends directly on the low-level Worker.

Problem: the boss only understands Worker. A Robot or an Intern can’t be managed without changing Manager, and tests can’t substitute a fake worker.

The good example:

Manager now depends only on the abstraction:

Bad code: Manager → Worker (tightly coupled). Good code: Manager → IWorker ← Worker, RobotWorker (loosely coupled and flexible). New workers such as RobotWorker, AIWorker or InternWorker need no change to Manager, which also makes Manager open for extension (OCP).

Component design models both the internal structure and the behaviour of a component.

The internal structure is modelled with a class diagram (as in Lecture 2).

The internal behaviour is modelled with a sequence diagram.

Reading the “Activate Sensors” example:

1: timer expires

An outside event reaches the ScheduleManager (sm).

2: getMsg() / 4: interpretMsg()

It fetches the scheduled message from s : Schedule and interprets it (a self-call).

alt frame

A choice: if msgId == HEAT_MSG_ID it sends 5: activate() to the HeatSensor; if msgId == VIBRATE_MSG_ID it sends 6: activate() to the VibrationSensor. Only one branch runs.

Make sure the problem is well defined: know all design criteria, requirements and constraints before starting the design.

What comes before how: at every level of abstraction, define the functions to be performed before choosing the structures that implement them.

Separate orthogonal concerns: don’t connect what is independent (orthogonal = unrelated, changing for different reasons).

External before internal: first treat the solution as a black box and decide how it interacts with its environment; then decide how the box is organised inside, usually as smaller black boxes refined the same way.

Keep it simple: fancy designs are buggier, harder to implement and verify, and often slower. Problems that look complex are often simple problems huddled together; the designer’s job is to separate them and solve each one.

Work at multiple levels of abstraction: good designers move quickly between the big picture and the details.

Design for extensibility: a good design is “open-ended”, easy to extend. Don’t introduce what is immaterial (unimportant) and don’t restrict what is irrelevant (unrelated): both make later extension harder.

Rapid prototyping: before implementing, build a high-level prototype and check that the design criteria are met.

Details depend on abstractions; abstractions don’t depend on details: the DIP stated as a rule of design.

Common closure: classes in a released component should change together; if one needs to change, they all probably do (“what affects one, affects all”). Group classes by the reasons they change.

Common reuse: classes in a released component are reused together; you can’t take part of a component.

Stable dependencies: dependencies between components must run in the direction of stability. The component depended on (dependee) must be more stable than the one depending on it.

Stable abstractions: the more stable a component is, the more it should consist of abstract classes; a completely stable component contains nothing but abstractions. That is why interfaces sit at the stable end of DIP diagrams.

Depth-first design: perfecting one part early and only partially satisfying the requirements overall. Experience is the best cure.

Directly refining the requirements specification into a design: produces overly constrained, inefficient designs, because the structure copies the document instead of the problem.

Failing to consider potential changes: always design for extension and contraction (adding and removing features).

Making the design too detailed: over-constrains the implementation and leaves programmers no sensible choices.

Recap: the internal-component design principles (the slide lists SRP and DIP; this lecture added ISP and DIP to Lecture 2’s SRP, OCP and LSP).

Internal behaviour is modelled with sequence diagrams, and the rules of design guide every decision.

Next chapter: creational design patterns.

The rules from slides 16–20 in one list. Problem and requirements first; what before how; separate independent concerns; design external behaviour first.

Keep it simple; work at several abstraction levels; design for extensibility; avoid the unnecessary; prototype early.

Depend on abstractions, not details (DIP).

Component rules: classes that change together and are reused together belong in one component; dependencies go toward stability; stable components should be abstract.

How analysis (requirements) models turn into design models. Left: the analysis models describe the problem.

The domain model class diagram (Customer, Order) becomes the design class diagrams (with attributes and operations such as changeName(), shipOrder()); use case diagrams and activity diagrams feed the component and interaction (sequence) diagrams.

System sequence diagrams become detailed interaction diagrams; requirements state machines (Ready → Shipped) become design state machines; and package diagrams organise the result into layers. Each design model traces back to an analysis model.