【抽象那些事】不完整的抽象&多方面抽象&未用的抽象&重复的抽象

不完整的抽象

抽象未支持所有互补或相关的方法时，将导致这种坏味。

为什么要有完整的抽象？

一种重要的抽象实现手法是创建内聚而完整的抽象。抽象未支持相关的方法时，可能会影响抽象的内聚性和完整性。如果抽象只支持部分相关的方法，其使用者就可能不得不自己去实现其他的功能。客户程序可能尝试直接访问抽象的内部实现细节，此时带来的副作用是违反封装原则。

一些常见的互补方法对

Min/Max	Open/Close	Create/Destroy	Get/Set
Read/Write	Print/Scan	First/Last	Begin/End
Start/Stop	Lock/Unlock	Show/Hide	Up/Down
Source/Target	Insert/Delete	First/Last	Push/Pull
Enable/Disable	Acquire/Release	Left/Right	On/Off

现实考虑

禁止特定行为

设计人员可能有意识地做出不提供堆成或配套方法的设计决策。例如在只读集合中，包含Add()方法，而不包含Remove()方法。

使用单个方法而不是成对的方法

例如用SetEnabled(bool)替换Enable()和Disable(),传入true代表启用，fasle代表禁用。

多方面抽象

抽象被赋予不止一项职责时，将导致这种坏味。

为什么不可以有多方面抽象？

单一职责原则指出，抽象必须承担单一而明确的职责，且必须完全封装该职责。抽象承担了多种职责时，意味着它将受多种原因的影响而需要修改，设计的修改频率与其缺陷数之间存在很强的正相关关系。这意味着多方面抽象存在的缺陷可能更多。

多方面抽象的潜在原因

通用抽象

引入使用通用名（如Item,Order,Product，Image）的抽象时，它常常会成为占位符，用于提供所有相关（但未必属于它）的功能。抽象的命名代表了这个抽象的职责，命名太通用，随着系统的迭代，抽象会慢慢承担多种职责。感同身受！！！

未定期重构

对类进行了大量修改而没有定期重构，长此以往，可能就会在类中引入了额外的职责。

混合关注点

没有对关注点分离给予足够的重视。

重构建议

类承担了多种职责时，就不是内聚的。可以使用“提取类”来进行重构。

未用的抽象

创建的抽象未用（未被直接使用或继承）时，将导致这种坏味。有以下两种表现形式：

• 未引用的抽象：未用的具体类
• 鳏寡抽象：没有任何派生抽象的接口/抽象类

为什么不可以有未用的抽象？

设计中的抽象未被使用，就没有发挥任何作用，因此违反了抽象原则。未实现的抽象类和接口时多余的或凭空想象出来的概括，因此是不需要的。

未用的抽象潜在原因

凭空想象的设计

试图设计"永不过时"的系统或在其中包含"未来可能用得着"的抽象时，将导致这种坏味。

不断变化的需求

需求不断变化，为满足早期需求而创建的抽象可能已经不再需要。如果将其留在设计中，它将变成未用的抽象。

维护过程中留下的垃圾

维护或重构时，如果不清理旧的抽象，可能留下未引用的抽象。这点深有体会，所以一直要求组员在重构的过程中，一定要把旧代码删除。如果不这样做，过期的和未用的代码将导致代码库急剧膨胀，重构的代码和未重构的代码纠缠在一起，代码的可理解性、阅读体验极差。而且如果你重构的旧代码你不负责删除，其他人就更不知道如何下手了，久而久之这些旧代码就会变成BUG的温床。注释掉旧代码也不是一个好的选择，太影响阅读体验。其次，现在的代码版本控制工具功能强大，即使删除错了代码，也可以通过版本控制工具找回。所以旧代码必须死。

担心破坏既有代码

不确定是否还有其他代码在使用想要删除的旧代码。

重构建议

将未用的抽象从设计中删除。对于可能还有客户程序在使用的API，直接删除不可行，可将这些抽象标记为''过期的''或"已摒弃",明确地指出在新开发的客户程序中不得使用它们。

[Obsolete]
public class Report
{
}

现实考虑

类库和框架通常以抽象类或接口的方式提供扩展点，这些抽象类可能在库或框架中未被使用，但它们是供客户程序使用的扩展点，因此不属于未用的抽象。

重复的抽象

两个抽象的名称、实现或两者相同时，将导致这种坏味。

• 名称相同

  两个不同的抽象重名将影响可理解性。

• 实现相同

  多个抽象的成员定义在语义上相同，但在设计上没有捕获并使用这些实现中相同的元素。在继承层析结构中，如果多个兄弟抽象的实现相同，可能意味着存在的是"未归并的层次结构"坏味。

• 名称实现都相同

为什么不可以有重复的抽象？

重复代码是软件万恶之首。所以我们要极力避免重复。

如果多个抽象的名称相同，将影响设计的可理解性：客户代码开发人员将不知道使用哪个抽象。

如果多个抽象的实现相同（代码相同），将难以维护：修改其中一个抽象的实现时，常常需要修改其它所有重复抽象的实现。这不仅增加了修改负担，还可能引入难以发现的微小BUG。为缩小修改范围，必须尽可能避免重复。

重复的抽象潜在原因

复制粘贴编程手法

CV程序员复制并粘贴代码，而不应用合适的抽象。

即兴维护

经过多年的修复或改进后，软件将包含"残留"，其中有大量重复的代码。

交流不畅

不同时期通常由不同的人员负责维护软件，他们对软件的了解不彻底，编写了原来就有的类或方法，导致软件包含重复的代码。

类被声明为不可扩展的

类被声明为不可扩展的，无法重用代码，只能复制代码，创建修订版本。

重构建议

对于名称相同的重复抽象，可以将其中一个抽象改为不同的名称。

对于实现相同的重复抽象，如果实现完全相同，可将其中一个抽象删除。如果实现稍有差异，可将相同的实现归并到另一个类中：这可以是层次结构中的基类，也可以是重复的抽象可引用或使用的既有类或新类。

现实考虑

适应变化

导致重复抽象的一个原因是，要同时支持同步和非同步变种。

在不同的上下文中使用相同的类型名

对于大型系统，建立完全统一的领域模型要么不可行要么不划算。领域驱动设计提供的一种解决方案是，将大型系统分成多个"界限上下文"。采用这种方式，不同上下文中的模型可能包含同名的类型，但是这是可以接受的。

语言未提供重复避免支持

在JDK中，有很多的重复的方法和类，这是因为没有对基本类型提供泛型支持。但是在.Net中就不会有这么多重复的方法和类，因为C#对基本类型提供了泛型支持。

参考：《软件设计重构》

作者：撸码那些事

来源：http://songwenjie.cnblogs.com/

声明：本文为博主学习感悟总结，水平有限，如果不当，欢迎指正。如果您认为还不错，不妨点击一下下方的【推荐】按钮，谢谢支持。转载与引用请注明出处。

微信公众号：