Abstractions Are More Stable Than Concretions

Photo by Serg Antonov on Unsplash

Can we identify a category of ‘programming things’ that, as a rule, experience less change than another such category?

Yes, we can: Abstractions change less than Concretions.

Abstractions are interfaces, delegates or function pointers, and abstract classes.

Concretions are concrete classes and concrete functions.

Why are abstractions more stable than concretions? 

When we modify an abstraction, dependent concretions must change in lockstep. However, the reverse is not always true. When a concretion changes, there is a good chance it won’t affect a related abstraction.

Note: Much of software architecture is concerned with designing abstractions that remain unaffected by changes to concretions.

This is all very abstract. Let’s get concrete with a simple example:

Below is the definition for an IPersonNameFormatter interface, an abstraction:

  public interface IPersonNameFormatter
  {
     string Format(string firstName, string lastName);
  }

and here is an implementor, a concretion: 

  public class PersonNameFormatter : IPersonNameFormatter
  {
     public string Format(string firstName string lastName)
     {
        return $"{firstName} {lastName}";
     }
  }

How do you think renaming method Format() to FormatName() in the interface will affect implementers?

  public interface IPersonNameFormatter
  {
     string FormatName(string firstName, string lastName);
  }

Correct. Concrete class PersonNameFormatter must reflect the name change:

  public class PersonNameFormatter : IPersonNameFormatter
  {
     public string FormatName(string firstName string lastName)
     {
        return $"{firstName} {lastName}";
     }
  }

A change in the abstraction affects concretions.

Now, let’s change the concrete class. We’ll alter how PersonNameFormatter outputs the name. Let’s change it from 

  ("Bob", "Smith") => "Bob Smith"

to

  ("Bob", "Smith") => "Smith, Bob"

Here goes:

  public class PersonNameFormatter : IPersonNameFormatter
  {
     public string FormatName(string firstName string lastName)
     {
        return $"{lastName}, {firstName}";
     }
  }

A change in the FormatName() implementation does not affect abstraction IPersonNameFormatter.

Abstractions are more stable than concretions.

Let’s also remember what we found out before:

Stable things should not depend on volatile things.

Combine them, and we have the makings of SOLID’s Dependency Inversion Principle (DIP):

Abstractions should not depend on concretions. 

Concretions should depend on abstractions. 

Please remember: 

Abstractions are more stable than concretions.