Listing Vault SE322 · chapter 05 · Principles of Detailed Design

Chapter 05 — Principles of Detailed Design

The detailed-design workflow, object-oriented modeling, cohesion and coupling ladders, SOLID, composition over inheritance and the named code smells.

05chapter
—lists
—total items
05

Principles of Detailed Design

14 lists

Detailed-Design Tasks 8

  1. Understand the architecture and the requirements
  2. Design external interfaces
  3. Design internal interfaces
  4. Design the GUI
  5. Design component structure and behavior
  6. Design data and the database
  7. Evaluate and document the design
  8. Manage implementation of the design

Design Documentation Artifacts 3

  1. Interface control documents
  2. Data dictionaries
  3. Version-controlled design records

OO Relationships 5

Relationship Meaning Lifetime
Association One class uses or refers to another Independent
Aggregation Has-a, shared parts Part survives the whole
Composition Has-a, exclusive parts Part dies with the whole
Generalization Is-a (inheritance) —
Realization A classifier implements an interface —

Class Kinds 2

  1. Abstract — defers some implementation, cannot be instantiated
  2. Concrete — fully implemented, can be instantiated

Cohesion Ladder 7

Weakest at the top, strongest at the bottom.

  1. Coincidental
  2. Logical
  3. Temporal
  4. Procedural
  5. Communicational
  6. Sequential
  7. Functional ← the goal

Coupling Ladder 5

Worst at the top, preferred at the bottom.

  1. Content ← worst
  2. Common
  3. Control
  4. Stamp
  5. Data ← preferred

Ways to Reduce Coupling 3

  1. Program to interfaces
  2. Communicate through events
  3. Invert dependencies

Abstraction & Encapsulation Rules 4

  1. Program to contracts, not concrete details
  2. Information hiding localizes likely change
  3. Encapsulation includes behavioral invariants, not only private fields
  4. Parnas: modularize around the decisions most likely to change

SOLID 5

Principle Statement Violation cue
S — Single Responsibility One reason to change; aligned to one actor A class serving finance and operations at once
O — Open/Closed Open to extension, closed to modification A growing switch statement edited for every new case
L — Liskov Substitution Subtypes must preserve client expectations An override that throws UnsupportedOperationException
I — Interface Segregation No client depends on operations it does not use Implementers stubbing out methods they never need
D — Dependency Inversion Policy and detail both depend on abstractions The domain importing the database driver

LSP Rules 2

  1. A subtype may not strengthen preconditions
  2. A subtype may not weaken postconditions

Dependency Inversion — The Detail 3

  1. The abstraction is owned by the high-level module, so the detail conforms to policy
  2. Dependency injection supplies collaborators from outside
  3. DI is a mechanism; DIP is the goal — you can have one without the other

Composition over Inheritance 3

  1. Inheritance binds subclass to superclass implementation at compile time
  2. Composition can be reconfigured at run time
  3. Composition avoids the fragile base class problem

Named Code Smells → Refactoring 6

Smell Usual refactoring
Long method Extract method
Large class Extract class
Long parameter list Introduce parameter object
Shotgun surgery Move method / move field to gather the change
Feature envy Move method to the class it envies
Duplicated code Extract method, pull up to a common place

Refactoring Ground Rules 3

  1. Refactoring is behavior-preserving by definition
  2. Automated tests make safe incremental refactoring possible
  3. Smells indicate design pressure, not an automatic rewrite command