Oop 依赖抽象有什么明显的缺点吗？
在阅读了关于稳定抽象原则（SAP）的维基之后，我想知道是否有人知道依赖抽象而非具体的缺点（我想，这超过了优点）Oop 依赖抽象有什么明显的缺点吗？,oop,design-patterns,architecture,package-design,Oop,Design Patterns,Architecture,Package Design,在阅读了关于稳定抽象原则（SAP）的维基之后，我想知道是否有人知道依赖抽象而非具体的缺点（我想，这超过了优点） SAP声明，包越稳定，它就应该越抽象。这意味着，如果一个包不太稳定（更有可能改变），那么它应该更具体。我真的不明白为什么会这样。当然，在所有情况下，无论稳定性如何，我们都应该依赖抽象并隐藏具体实现？首先，从您链接到的论文中： 稳定性不是衡量模块运行的可能性 改变相反，这是一个衡量改变模块难度的指标 因此，难以更改的内容（例如，在许多地方使用）应该是抽象的，以使扩展变得容易/可能 是的，
SAP声明，包越稳定，它就应该越抽象。这意味着，如果一个包不太稳定（更有可能改变），那么它应该更具体。我真的不明白为什么会这样。当然，在所有情况下，无论稳定性如何，我们都应该依赖抽象并隐藏具体实现？首先，从您链接到的论文中： 稳定性不是衡量模块运行的可能性 改变相反，这是一个衡量改变模块难度的指标 因此，难以更改的内容（例如，在许多地方使用）应该是抽象的，以使扩展变得容易/可能 是的，也有缺点。这是改变的容易。更改具体的代码比更改抽象和代码更容易、更快 毫无疑问，在任何情况下，无论稳定与否，我们都应该依靠它 抽象和隐藏具体的实现 这是真的。但是抽象的层次不同。动态示例：如果我要求您计算正方形对角线的长度，那么您可能只需要使用内置的
double sqrt（double）因此，如果您的包经常更改，那么它最好提供具体内容，而不是抽象内容。否则。。。谁会用它？；） 罗伯特·C·马丁描述事物的方式总是相当晦涩。他的观点总是很好，但需要一点解释——“传入与传出耦合”，啊！马丁写作方式的另一个特点是，它总是在描述性和规定性之间模糊不清（“愿意”或“应该”？） “稳定性” 首先，理解Martin如何定义“稳定性”很重要。他根据产生稳定性度量的传入和传出耦合对其进行了定义：
instability = efferent / (efferent + afferent)
instability = outgoing / (outgoing + incoming)
Maximum independence = "stable root" (as I'm calling it)
Maximum dependence = "unstable leaf" (as I'm calling it)