Stable Abstractions Principle

SAP:

: Packages that are maximally stable should be maximally abstract. Unstable packages should be concrete. The abstractness of a package should be in proportion to its stability. (http://www.objectmentor.com/resources/articles/stability.pdf)

One of the PrinciplesOfObjectOrientedDesign. Closely related to the StableDependenciesPrinciple.

Also see OpenClosedPrinciple. The reliable part is "closed" but subclassing is "open".

I think that maybe the "should be"s in that should be replaced with "will tend to be"s. Abstract base classes and interfaces are the most stable things in the system -- every time one of them changes it forces a bigger change in one or more other classes. -- PhilGoodwin

In some domains, stable abstractions are difficult to come by. Anything and everything is subject to change. At best one can make an educated guess and assign probabilities. And one must consider the "cost of failure" of getting the abstraction wrong (in the future). Some designs bet heavily on abstraction assumptions and are tightly married to those assumptions. It may make life easy when the future changes are as planed, but if foundation abstractions turn out not to be sufficient, then you are screwed.

An example is hierarchies. I have designed reporting systems around hierarchies and assumptions of hierarchies because they had been using hierarchies without problems for many decades (including the manual era). One day a set-oriented (cross-branch) requirement comes along and kicks the system in the butt. All the hierarchy-based conventions, patterns, and interfaces are completely useless for the new stuff. It was the right decision based on what was known at the time, for set-based interfaces are difficult to make intuitive for most users such that you don't want it unless there is a known reason.

In modelling real-world domains -- the world of customers, employees, invoices, bills-of-materials, products, SKUs, paycheques, etc. -- stable abstractions may be difficult to find. Computational domains -- the world of stacks, queues, functions, trees, processes, threads, graphical widgets, reports, forms, etc. -- are much more likely to be stable.