糟糕的面向对象设计的特征
Characteristics of bad object oriented design
我正在阅读面向对象的设计原则。我发现了糟糕设计的特征。
- It is hard to change because every change affects too many other
parts of the system. (Rigidity)
- When you make a change, unexpected parts of the system break.
(Fragility)
- It is hard to reuse in another application because it cannot be
disentangled from the current application. (Immobility)
前两个我能看懂，第三个对我来说有点难懂。
它是关于在 Base class 中提取相关 class 的共同特征，从重复的代码中制作方法吗？但它说 hard to reuse in another Application. 通常我们编写上下文特定的代码并且 Over-engineering 不是一个好主意，我们有像 YAGNI 这样的好原则（你不会需要它）我发现这些想法很少自相矛盾。
请为此提供您的宝贵意见。
移动示例：
假设以下 classes:
- 动物
- 犬类
- 狗
如您所料，Canine 扩展了 Animal，Dog 扩展了 Canine。
设计不佳 Animal 的一种方法是给它一个打印出 bark 的方法 talk()。或许，此应用程序的初衷是仅供狗使用，因此 talk 方法 barking 没问题。但是在另一个代码库中重用它会导致问题。
假设我们要扩展 Animal 并创建 Bird。鸟不叫:)
很难想象有人会这样做。但它一直在发生。基础 classes 没有被抽象出来，这导致代码放错地方，使得 correct/reuse 变得困难。
有人可能会争辩说 Bird class 可以覆盖 talk 方法。这会起作用，但是，出于另一个原因扩展 Animal 的另一个开发人员可能会忘记覆盖该方法......等等
我知道这不是最好的例子，但它说明了问题。
我正在阅读面向对象的设计原则。我发现了糟糕设计的特征。
- It is hard to change because every change affects too many other parts of the system. (Rigidity)
- When you make a change, unexpected parts of the system break. (Fragility)
- It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility)
前两个我能看懂，第三个对我来说有点难懂。
它是关于在 Base class 中提取相关 class 的共同特征，从重复的代码中制作方法吗？但它说 hard to reuse in another Application. 通常我们编写上下文特定的代码并且 Over-engineering 不是一个好主意，我们有像 YAGNI 这样的好原则（你不会需要它）我发现这些想法很少自相矛盾。
请为此提供您的宝贵意见。
移动示例：
假设以下 classes:
- 动物
- 犬类
- 狗
如您所料，Canine 扩展了 Animal，Dog 扩展了 Canine。
设计不佳 Animal 的一种方法是给它一个打印出 bark 的方法 talk()。或许，此应用程序的初衷是仅供狗使用，因此 talk 方法 barking 没问题。但是在另一个代码库中重用它会导致问题。
假设我们要扩展 Animal 并创建 Bird。鸟不叫:)
很难想象有人会这样做。但它一直在发生。基础 classes 没有被抽象出来，这导致代码放错地方，使得 correct/reuse 变得困难。
有人可能会争辩说 Bird class 可以覆盖 talk 方法。这会起作用，但是，出于另一个原因扩展 Animal 的另一个开发人员可能会忘记覆盖该方法......等等
我知道这不是最好的例子，但它说明了问题。