Skip to content

Latest commit

 

History

History
83 lines (59 loc) · 4.42 KB

SoftwareArchitectureCheetsheet.md

File metadata and controls

83 lines (59 loc) · 4.42 KB

Software Architecture Cheat Sheet for Daily Usage

Software Architecture smells and heuristics

Having clean software architecture and staying conform to pre-defined design principles from start of the project is one of the best ways to avoid possible technical debt in the future of that software system. Clean Software Design is a key point for an effective software product.

Let us have a look at some important principles, rules, guidelines that ensure a clean software design:


Principles:

  1. Loose Coupling — if classes use each other, they are coupled together. The less classes are coupled, the easier is to change them.
  2. High Cohesion — degree to which elements of a whole belong together. Components of the class should be highly cohesive.
  3. Only Local Changes — Changes, maintenance, extensions are only local. This leads to no harming whole environment.
  4. Easy to Remove — Software Components should be easily removeable.
  5. Small Components — software system should be only of small components ideally each doing only one task.

Class Design:

  1. Single Responsibility Principle (SRP) — class should do only one task.
  2. Open Closed Principle (OCP) — class should be extended not modified.
  3. Liskov Substitution Principle (LSP) — derived classes must be substitutable for their base classes.
  4. Dependency Inversion Principle (DIP) — depend on abstractions, not on concretions.
  5. Interface Segregation Principle (ISP) — interfaces should be fine-grained
  6. Classes Should be Small.
  7. Do stuff or know others, but not both.

Cohesion Principles:

  1. Release Reuse Equivalency Principle (RREP) — only together releaseable components should be bundled together.
  2. Common Closure Principle (CCP) — classes that change together should be bundled together.
  3. Common Reuse Principle (CRP) — classes that are used together should be bundled together.

Coupling Principles:

  1. Acyclic Dependencies Principle (ADP) — no dependency cycles.
  2. Stable Dependencies Principle (SDP) — depend on direction of stability.
  3. Stable Abstractions Principle (SAP) — the more abstract, the more stable.

High-Level Design:

  1. Keep Configurable Data at High Levels — constants or config datas should be kept in high level.
  2. Don’t Be Arbitrary — have a convention, principle, rule or guidelines and always follow them.
  3. Prefer Polymorphism To If/Else or Switch/Case.
  4. Symmetry / Analogy — Favour symmetric designs (e.g. Load — Save) and designs that follow analogies (e.g. same design as found in .NET framework).
  5. Separate Multi-Threading Code — isolate multi-thread from rest of the code.
  6. Code at Wrong Level of Abstraction — stay conform to existing abstraction layers.
  7. Fields Not Defining State — fields holding data that does not belong to the state of the instance but are to hold temporary data. Use local variables or extract to a class abstracting the performed action.
  8. Micro Layers — avoid unnecessary design layers.

Environment:

  1. Project Build Requires Only One Step.
  2. Executing Tests Requires Only One Step.
  3. Source Control System — Always use a source control system.
  4. Continuous Integration — Assure integrity with Continuous Integration.
  5. Overridden Safeties — Do not override warnings, errors, exception handling

Dependencies:

  1. Make Logical Dependencies Physical — If one module depends upon another, that dependency should be physical not just logical. Don’t make assumptions.
  2. Singletons / Service Locator — Make use of dependency injection.
  3. Base Classes Depending On Their Derivatives — Base classes should work with any derived class.
  4. Feature Envy — The methods of a class should be interested in the variables and functions of the class they belong to, and not the variables and functions of other classes. Using accessors and mutators of some other object to manipulate its data, is envying the scope of the other object (c).
  5. Artificial Coupling — Things that don’t depend upon each other should not be artificially coupled.
  6. Hidden Temporal Coupling — If the order of some method calls is important, then make sure that they cannot be called in the wrong order.
  7. Transitive Navigation — (Law of Demeter), writing shy code. A module should know only its direct dependencies.