Software Design

Software Quality

  • Software Quality is not tradable
  • Quality can be defined in terms of design, number of defects, performance, etc
  • Software quality can have 2 aspects: Internal (code) or external (UI)
  • Unfortunately it is assumed that with less design (less quality) we gain more speed. Reducing internal quality slows us down in the long run.

Design and XP

  • In XP evolutionary design is recommended instead of a big upfront (planned) design. Notice that some upfront design/architecture is always needed at the beginning.
  • Software change curve: As the software grows, it becomes exponentially more difficult to make changes. In XP this diagram should be flat and then it makes doing changes easy. The most important things that help make this diagram flat are: testing, refactoring and CI. These make evolutionary design possible.
  • YAGNI (You Aren't Going to Need It) is one of the values of XP and simple/evolutionary design. It basically says that you only should add code that is needed for a feature we need today not tomorrow. I don't really like this!
  • Principles of xp seem to underestimate using patterns but that should not be the case. Patterns of the basis of design/development regardless of methodology used.
  • xp and architecture: It looks like that xp doesn't like architecture and prefers to jump on code as fast as possible. I don't like this either. some insight on design/architecture is always needed.
  • xp appears to de-emphasis diagrams but they are needed to some extend for communication not probably as an artifact.


  • A lack of will to design seems to be a major reason why evolutionary design can fail (Martin Fowler)
  • Grady Booch: Have an object oriented view on the world rather than an algorithm-based viewpoint. Think about things not processes.

SOLID Principles

SOLID is an acronym for the following 5 principles of object oriented design:

Single responsibility

A class should have only a single responsibility. A class with 2 responsibilities should be split into 2 classes.


Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification; that is, such an entity can allow its behaviour to be modified without altering its source code. Use of inheritance is suggested to achieve this but techniques and result are different.
Method 1: Implementation inheritance
Method 2: Using abstract base classes. Interface specifications can be reused through inheritance but implementations need not be.
What about changing through configuration?

Liskov substitution

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Interface segregation (separation)

No client should be forced to depend on methods it does not use. ISP splits large interfaces into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.
Many client-specific interfaces are better than one general-purpose interface.
Xerox example by Robert Martin.

Dependency inversion

The goal of the dependency inversion principle is to decouple high-level components from low-level components such that reuse with different low-level component implementations becomes possible. This is facilitated by the separation of high-level components and low-level components into separate packages/libraries, where interfaces defining the behaviour/services required by the high-level component are owned by, and exist within the high-level component's package.
Various patterns such as Plugin, Service Locator, or Dependency Injection are then employed to facilitate the run-time provisioning of the chosen low-level component implementation to the high-level component.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License