Aferente
Se algo usa um monte de coisas diferentes (alto número de acoplamentos aferentes), é provável que ele se quebre se alguma dessas coisas mudar.
Instabilidade = 1
Eferente
Se algo é usado por um monte de coisas diferentes (alto número de acoplamentos eferentes), então pode haver uma tendência a quebrar muitas coisas se mudar.
Instabilidade = 0
Estabilidade
A definição de Martin de "estabilidade" é uma mistura exótica entre "difícil de mudar" e "com poucas razões para mudar". No entanto, sua métrica de instabilidade descreve apenas "dificuldade de mudança". Os "motivos para mudar" terão muito mais a ver com fatores que não podem ser facilmente calculados, como apenas projetar suas interfaces adequadamente, em um nível apropriado de abstração e entender os requisitos do usuário com mais clareza.
Então, um acoplamento eferente alto com um acoplamento aferente baixo produz estabilidade (como em algo difícil de mudar, pois isso quebra um monte de coisas), o oposto gera instabilidade (como em algo fácil de mudar, pois não quebra um monte de coisas) .
Um grande número de acoplamentos aferentes pode ser um indicador de que seu projeto não tem foco - ele está usando um monte de coisas diferentes, então talvez não tenha uma responsabilidade clara e singular.
Um grande número de acoplamentos eferentes poderia inicialmente ser interpretado como algo realmente bom, pois indica que seu projeto está sendo amplamente (re) utilizado. No entanto, isso seria ruim se você se sentir tentado a mudar o design com frequência, de maneira a quebrar tudo. Portanto, com um grande número de acoplamentos eferentes, é necessário que esses pacotes tenham "poucas ou nenhuma razão para mudar". Os projetos devem ser estáveis no sentido ideal de não ter motivos para mudar, pois também serão muito difíceis de mudar.
Princípio de abstrações estáveis
Conceitos como inversão de dependência (que naturalmente exige injeção de dependência) e SAP (princípio de abstrações estáveis) sugerem que as dependências fluem para abstrações. E há uma razão simples para considerar a "estabilidade" no contexto de "poucas razões para mudar". Uma interface abstrata não menciona detalhes concretos, concentra-se apenas em "o que fazer" em vez de "o que as coisas são" e, portanto, tem menos razões para mudar. A porta gráfica acelerada em nossas placas-mãe (interface abstrata) tem menos motivos para sofrer uma alteração no design do que a GPU que se conecta a ela (um detalhe concreto).
Reutilização x Reutilização
Um tipo de métrica pessoal, se eu puder sugerir uma que colidir um pouco com a de Martin, é essa noção que gosto de insistir em que as bibliotecas mais reutilizáveis devem procurar reutilizar minimamente outro código. Isso leva a instabilidade a um valor zero. É pelos motivos práticos de ter motivos mínimos para mudar, mas também para promover a biblioteca mais fácil de implantar. Uma biblioteca de uso geral e amplamente usada, que depende de uma dúzia de bibliotecas diferentes, tem muitos motivos para mudar, além de uma distribuição de pacotes desajeitados que pode ser difícil de implantar. A diferença aqui é que "razões para mudar", no meu caso, se estendem até a implementação, pois é proveniente de uma visão orientada à biblioteca que procura liberar versões estáveis da biblioteca. Martin pode desconsiderar a implementação como uma parte muito separada,
Do ponto de vista da distribuição, a implementação e a interface se confundem para gerar dependências do usuário em uma biblioteca estável ou instável. Do ponto de vista da interface, apenas a interface é usada e os detalhes da implementação associados são completamente separados.