the first dependency management rule.

December 27, 2023

2023   ·   software  

This principle keeps the User/Actor in the center of the design.

Every Module, Class, Function has single reason to exist and change.

In other words, Each Module, Class, Function should have:

  1. 1 Responsibility or Task
  2. 1 Source of Change
  3. 1 Reason to Exist

All these three are governed by the ACTOR/USER.

Let’s take a simple example to explain the need for this Rule.

Here Employee class is serving three types of ACTORS:

  1. Accountant team: Who need to calculate pay time to time.
  2. Tech Leads: Who might change the db interaction based on need
  3. Operations team: Who check employee details for many usecases.

Main thing to note here is:

  1. Tech Leads does not use calculatePay(), describeEmployee() in fundamental way.
  2. Accountants do not care about how saved to db
  3. And Operations team do not care about pay values.

If we go bottom up for SRP verification:

  1. Functions: Follow SRP
  2. Class: Do Not Follow SRP
  3. Module: Do Not Follow SRP (If considered)

Some of the granular problems this Class will face are:

  1. Collision: When two departments or actors try to make changes to the same class they often face merge conflicts or some other race conditions.

  1. Fanout-Fragility: If a particular class has too many dependencies over multiple low level abstractions. It becomes so sensitive to system wide changes. And the Derived classes which use this class are also bound to be sensitive and fragile. (Easily breakable)

Here, if the String API that describeEmployee depends on breaks, the class will not compile and affect Accountants, who does not have anything to do with String API.

  1. Colocation: Once two responsibilities are coupled or colocated by accident, other couplings tend to accumulate over time. Such as different actors use a sharing method or some other shared variable.

Here, Developers used the same method for both accountants and operations to calculate hours, if the Accountants, change the definition for totalHours(), then the operations need to fix their implementation. And doing this cross team communication is difficult.

An Ideal Solution for this situation is to Isolate all the three ACTORS and also the Classes or Modules.

Some of the Design Solutions that can be think or tried off are:

  1. Invert Dependencies
  2. Extract Classes
  3. Facade
  4. Interface Segregation

Quick Reads: