Tag: component coupling

Clean Architecture – Chapter 14 | Component Coupling | SAP | The Stable Abstractions Principle

May 27th, 2023

So far we have discussed The Acyclic Dependency Principle and Stable Dependencies Principle, in this post we will go through Stable Abstractions Principle

A component should be as abstract as it is stable.
Robert Martin

High level architecture/policies are part of software and they should be present in a component that is stable, because we don’t want them to change often. However, if we put these high level policies into a stable component, then the code representing these policies would be difficult to change. And that could make the overall architecture inflexible.

So where should we put these policies so that they are stable as well as flexible. The answer is Open Closed Principle. This principle as we have seen gives us the opportunity to have classes that can be easily extended without modification using Abstract classes.

We can see that SAP creates a relationship between stability and abstractions. It says that a stable component should also be abstract so that it’s stability does not prevent it from being extended. So, for a component to be stable, it should contain interfaces and abstract classes.

SAP + SDP = DIP for components

SDP says dependencies should run in the direction of stability. SAP says stability implies abstraction . So dependencies run in the direction of abstraction.

Measuring Abstraction

Abstractions A = Na / Nc

where Na -> number of abstract classes and interfaces in the component

Nc -> number of classes in the component

A ranges between 0 and 1, 0 means component has no abstractions, 1 means, component has only abstract classes and interfaces.

The Main Sequence

Components on (0, 1) are maximally stable and abstract. Components at (1, 0) are maximally unstable and concrete. Other components lie on the line between these two components depending on the degree of stability and abstraction.

The Zone of Pain

Component on (0, 0) is highly stable and concrete. It is rigid. It cannot be extended as it’s not abstract, It is difficult to change because of its high stability. The area around (0, 0) is called zone of pain.

There are few components that lie in this area. Example – Database schema. These are volatile and concrete and many components depend on them.

Non volatile components are harmless in this zone as they don’t change. Only the volatile components cause pain like database schema mentioned above.

The Zone of Uselessness

Component at (1, 1) is maximally abstract and has no dependents. These components are useless and so the zone is called zone of uselessness.

These are generally dead code often leftover from abstract classes that never were implemented.

Main Sequence

Components that lie on this line are not “too abstract” or “too stable”. It is depended on to the extent that it is abstract and it depends on others to the extent it is concrete. As good architects, we should try to place our components on this line.

Distance from the main sequence

Distance or D = | A + I -1 |, range is between (0, 1). 0 indicates component is on main sequence, 1 indicates it is far from main sequence.

Using this metric, design can be analyzed for its overall conformance to main sequence. We can calculate D metric fir each component. Then based on its value, component can be evaluated and changed.

Thanks for stopping by! Hope this gives you a brief overview in to Stable Abstractions Principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 14 | Component Coupling | SDP | The Stable Dependencies Principle

May 20th, 2023

In our previous post, we discussed The Acyclic Dependency Principle, in this chapter we will go over next principle called SDP (Stable Dependencies Principle)

Depend in the direction of stability
Robert Martin

We need to ensure modules that are easy to change should not be depended on by modules that are harder to change.

What is a stable component?

Let’s say we have module X, and we have three modules that depend on X. Then X is referred to as Independent or Stable component as it has no external reason to change.

Let’s say, we have module Y which depends on three modules, so any change in any of those three modules would cause Y to change and so Y is referred to as Dependent.

Stability Metrics

Fan-in – Number of incoming dependencies, i.e., number of classes outside component that depend on classes within the component.

Fan-out – Number of outgoing dependencies, i.e., number of classes inside component that depends on classes outside the component.

Instability –

I = Fan-out / (Fan-in + Fan-out)

The range of this metric is between 0 and 1.

I = 0 => maximally stable component, component X from above example

I = 1 => maximally unstable component, component Y from above example

As per SDP, I of a component should be larger than I of the components that it depend on. I should decrease in direction of dependency.

Not all components should be maximally stable as that would create a very rigid system. We need a balance of stable and unstable components. Ideally in our system, we should have unstable components on top and then should be depending on stable components at bottom.

Thanks for stopping by! Hope this gives you a brief overview in to Stable Dependencies Principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.
Clean Architecture – Chapter 14 | Component Coupling | The Acyclic Dependency Principle

May 13th, 2023
So far we have gone through defining component and understanding what makes a component in previous chapters. In this post we start looking into principle that talk about the relationships between component. Let’s start with the acyclic dependency principle.

Allow no cycles in the component dependency graph
Robert Martin

A very common scenario that we developers face – We are working on a project, make some code changes, verify it’s working, so log out for day/commit the changes. Next day or few days later, we find that our integration tests are failing! Root cause comes out to be a change in one of our dependencies. This leads to either reverting our change or working on fix. The author calls this “morning after syndrome”.

Solution to this problem of running into frequent changes caused by changes in dependencies – The Weekly Build

The Weekly Build

As per this, developers work for 4 days in a week on their code and on fifth day they integrate their changes and build the system.

Now this could work when the team is small/the system is small so there are fewer teams. But when the system would grow, components and teams owning those components would grow. Eventually we would find that it takes more time to integrate and so pushing the integration days one day back. Ultimately a build per week won’t be sufficient and we would starting doing a build every two weeks. This could increase to month!

Clearly this solution cannot work for large systems.

Dependency Cycles elimination

The solution is to partition the development environment into releasable components. Each component could have its release versions with each change. The components consuming these changed components can then decide to move to new version or keep using the previous ones. This reduces the dependencies between teams and they can work independently.

The key for this approach to work is – When components depend on other components, there should be no cycles.

Say we have three components A, B, C. A depends on B, B depends on C. There will be a cycle if C would depend on A. If there is no cycle, any changes in A would force changes in B and C. Any change in B would only force C to change, A is safe. Any change in C would not force any change in A or B.

However if there is a cycle, then any change in A, B or C would need changes in all components.

So if there are cycles in the way our component depends on each other, we need to break it –
1. Use DIP (Dependency Inversion Principle), invert dependency by using interfaces.
2. Add the common classes between two components to a third component and then depend on that component.
Top Down Design

When we start building the system, we could be grouping classes based on usability. Few iterations later, we might worry about reusability of components and start moving around classes by creating new components and new dependencies between them. We can see the component structure keeps on evolving based on the requirements at each stage of our development. And so we cannot design this structure at the beginning in top down manner.

Thanks for stopping by! I hope this gives a good preview into acyclic dependency principle. Eager to hear your thoughts and chat, please leave comments below and we can discuss.

Tag: component coupling

Clean Architecture – Chapter 14 | Component Coupling | SAP | The Stable Abstractions Principle

Measuring Abstraction

The Main Sequence

The Zone of Pain

The Zone of Uselessness

Main Sequence

Distance from the main sequence

Clean Architecture – Chapter 14 | Component Coupling | SDP | The Stable Dependencies Principle

What is a stable component?

Stability Metrics

Clean Architecture – Chapter 14 | Component Coupling | The Acyclic Dependency Principle

The Weekly Build

Dependency Cycles elimination

Top Down Design