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

RelationshipMeaningLifetime
AssociationOne class uses or refers to anotherIndependent
AggregationHas-a, shared partsPart survives the whole
CompositionHas-a, exclusive partsPart dies with the whole
GeneralizationIs-a (inheritance)—
RealizationA 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

PrincipleStatementViolation cue
S — Single ResponsibilityOne reason to change; aligned to one actorA class serving finance and operations at once
O — Open/ClosedOpen to extension, closed to modificationA growing switch statement edited for every new case
L — Liskov SubstitutionSubtypes must preserve client expectationsAn override that throws UnsupportedOperationException
I — Interface SegregationNo client depends on operations it does not useImplementers stubbing out methods they never need
D — Dependency InversionPolicy and detail both depend on abstractionsThe 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

SmellUsual refactoring
Long methodExtract method
Large classExtract class
Long parameter listIntroduce parameter object
Shotgun surgeryMove method / move field to gather the change
Feature envyMove method to the class it envies
Duplicated codeExtract 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