Software Design Cheat Sheet

A cheat sheet showing the most common quality measures and design principles.

Quality Measures

Measures that help you determine the quality of software.

Coupling

The strength of linkage between elements.

Guidelines

Elements change together? Couple them tightly.

Elements change independently? Couple them loosely.

Challenges

  1. Figuring out which elements change together
  2. Recognising coupling strength

Symptoms

Too Tight

When you change a small part in an isolated area unrelated features break.

Too Loose

When you make a simple focussed change needing to update code in many places.

Cohesion

The degree to which elements that belong together are placed together.

Guidelines

Elements are related to the same concept? Put them inside the same class.

Elements are unrelated? Move them into different classes.

Challenge

Defining which "concept" or "concern" to organise by.

Symptoms

Low Cohesion

  • Large classes that deal with many concerns.
  • Small changes cause lots of places to change

High Cohesion

  • Small, focussed classes.
  • Small changes are easy to make.

Coupling.

Encapsulation

Guidelines

Hide details inside an interface of an element.

Challenges

  • Figuring out the interfaces of objects so that each object hides the right things
  • The degree to which elements that belong together are placed together

Symptoms

Poor Encapsulation

  • Code deals with low level primitives - strings, dates etc
  • Classes that expose internals - getters, setters etc

Good Encapsulation

  • Code that trusts objects to do their jobs
  • Classes that hide their internals

Coupling. Abstraction. Primitive Obsession.

Design Principles

Principles that make code easy to work with.

Business > Technology

Definition

Prefer domain terms over technology terms.

Technology Terms

  • Databases - Postgres, MySQL, Redis
  • Protocols - HTTP, REST
  • Frameworks - .NET, Rails, Laravel

Domain Terms

  • Entities - Invoice, Customer, Company
  • Use Cases - Invoice Customer, Create Company
  • Business Rules - Invoices are due after 30 days, Customer must have an address

Guidelines

  • Create an infrastructure layer where technology specific language lives
  • Hide the how (Redis) with an abstraction describing the what (caching)

Challenges

  • Stopping obsessing over the technology
  • Figuring out how to isolate technoloy concerns

Symptoms

Technology Focussed

  • Technology details spread throughout the codebase
  • Technology upgrades or changes cause large changes
  • Difficult to understand business processes by reading the code

Business Focussed

  • Technology details isolated to small areas
  • Domain experts can read parts of the codebase and understand changes
  • New engineers can read the codebase and learn about the domain

Also Know As

What > How

Encapsulation. Abstraction.

Abstraction

Definition

Hide details behind a higher level interface.

Guidelines

  • Good abstractions hide the "how" (implementation) behind the "what" (interface)
  • Cost of every abstraction - one more layer to unwrap
  • Benefits of correct abstraction - changes become localised and easy to make

Symptoms

Too Few Abstractions

  • Code deals with low level primitives - strings, dates etc
  • Code is difficult to change and understand

Too Many Abstractions

  • Lots of layers of abstraction
  • Debugging is difficult
  • Classes or methods do very little

Wrong Abstractions

  • Small changes require changing many abstractions
  • Debugging is difficult
  • Code is intertwined and spaghetti-like

Business > Technology Encapsulation Coupling

Open / Closed Principle

Definition

Prefer writing new classes over modifying existing classes.

Guidelines

  • When changing behaviour, wrap up old behaviour in a class
  • Create new class with new behaviour, same interface
  • Swap old class for new class

Challenges

Creating the right abstracton to wrap up existing behaviour in a class.

Symptoms

Not Open Closed

  • Changes cause unrelated code to break
  • Small changes cause ripple effects across the codebase

Encapsulation. Abstraction. Polymorphism.

Polymorphism

Definition

Multiple classes with same interface but different behaviour.

Guidelines

Look for opportunities to make classes swappable.

Challenges

  • Evolving suitable interfaces
  • Choosing the correct abstractions

Encapsulation. Abstraction. Open / Closed Principle.

Tell Don't Ask

Definition

Prefer telling objects what to do rather than asking them questions.

Guidelines

  • Make communication one way
  • Inverting dependencies can help

Challenges

  • A very different way of thinking of design
  • Not always applicable

Encapsulation. Dependency inversion.

Dependency Inversion

Definition

Instead of calling an object that has behaviour, supply the behaviour to the object.

Guidelines

  • Useful to remove deeply embedded duplication
  • When stuck, can be a useful reframe - "what if these dependencies were inverted?"

Symptoms

Incorrect Dependency Direction

  • Removing duplication causes coupling that's too strong
  • Refactoring becomes difficult
  • Refactored code is too DRY and fragile
  • Calling object knows too much

Encapsulation. Abstraction.

Cookie 🍪
We use cookies to improve your experience on our site.