Stability is the ultimate goal of a system.
The stability of the system is eventually about the bottom line of business. Stability does not mean the system will not change; quite the opposite, the system would be easier to change/evolve because the system has a stable structure/architecture skeleton, which would lead to the benefits of these: the codebase would be smaller, the development cost would be lower, the quality of software would be higher(less code, less changes==less bugs), and the time to market would be faster.
The mechanism to achieve stability is through conscious system design, particularly system partitioning and abstraction.
But exactly how? extract and capture the static structure, the broadly defined intrinsic behavior of domain, which is totally independent of the context, and encapsulate the context using data. Or put it another way, identify and separate what is stable from what is volatile(context). The stable behavior portion would be represented by interfaces; interface should be very generic, about fundamental concepts of domain, the semantics. The abstraction level of interface is very high, so it would NOT require the interface to be changed even when business requirements change since the required change would be simply represented by a different context data.
Some indicators of the stability problem of the system. The number of methods in interface/type, and the number of interfaces in a system. Interface is an external view of the system. The more exposure you have, the less stable it would become because the system would expose volatile pieces(very specific description of system) which are subject to change. Once these 2 things are mixed, we have to change either the structure or behavior when a requirement changes. Interface is a firewall and boundary, we should not be able to see through it to know what is the detail behind it. It should be strong and withstand the test of time. Some research work was done by author Juval Lowy in his book published in 2005. Some of the content might be obsolete, but principles are still very much valid.
Some research work on .NET Framework 2.0.
If a developer were asked to create a single method vs as many methods as they would like in a type, the result would be drastically different, since the abstraction level would be quite different.
We achieve stability by encapsulating the volatile piece in the data. For example, int is a stable type(data structure), the context of 3 meals a day, 24/7 are represented by instantiating int type with value of 3, 24, 7 at run-time. But in our real practice, we might have the equivalent of meal int type, hour int type, and day-in-week int type. So when it is time to represent days of the year, we have to introduce day-in-year int type since we do not have a type that can capture all of the numbers in a fashion that is context-independent.
If we were asked to design an interface that can capture everything in the universe, in my view, it would look like this:
interface IHappened
{
string Happened()
}
What is your view on this topic? any comment is welcome.
Talk to you next time. 10/26/2019
More about interface, please take a look at this article and this article.