对于抽象稳定等价原则的深入思考

      在前一篇的《关于稳定依赖原则的深入思考》中，我提到，稳定性不等于独立性，如果这个理论成立，那么，这里的抽象稳定等价原则需要改为抽象独立等价原则吗？包越独立，其编译期的变更影响越小（减少客户代码被动修改的机会），而抽象的目的也是为了在编译期——而不是运行期对变更进行隔离（我的实现可以变，但我的客户代码不变），所以，我认为，抽象性应该与独立性相关，而不是稳定性——因为它是个运行期的概念；

      接着，我们再看看抽象独立等价的内涵，抽象的目的是为了获取“共性”，它将共性背后的“个性”变化与客户隔离开，“共性”的变更风险小，所以它才可以被放心地依赖，于是传入依赖可以多多，这同时意味着它承担的责任也是重重的，所以它要尽量减少对外的依赖，将自身被动改变的风险降到最低，因此，根据独立性的公式计算，其独立性必定是要高；反过来，如果一个包的独立性很高，也就是传入多于传出，意味着它的责任很重，为了减少变更的风险，它就需要让传入的方法仅仅依赖于抽象方法，隔离个性实现的变更。这实际上是在暗示：传入的依赖就是对抽象的依赖，所以，传入的依赖越多，对抽象的依赖就要越多，这才是根本的 ；

      然而，我们计算包的抽象性独立性等价的公式是这样的：D=|A+C-1|，其中，C就是独立性，A是抽象性，A=抽象类的数量/全部类的数量，试想，如果所有的传入依赖都依赖于抽象方法，并且所有实现类对外是不可见的，但抽象类的数量在包中的比例很低，这个公式的度量结果就会得出与抽象独立等价的内涵不一致的结果，所以，对于抽象性的度量，我个人认为，应该是从实际被依赖的方法数量进行考察——甚至不是类的数量，因此，公式是否应该是：A=传入的抽象依赖/传入的全部依赖，这样，抽象性独立性等价的内涵才得以真正体现。

 

抽象，也就是封装的一种，它带来的好处是设计上的，也就是说，拿编译期和运行期做判断，这个角度不是很准确。
抽象能减少依赖，可以减少设计上过分依赖，这样，在运行期和编译器都有提限，还有很多其他的好处。它定义做什么，而不在于怎么做，但是过分和不合理的抽象，不能反映问题域本身，可能引起很多其他方面的麻烦