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

不完整的抽象

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

为什么要有完整的抽象?

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

一些常见的互补方法对

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#对基本类型提供了泛型支持。

参考:《软件设计重构》

原文发布于微信公众号 - 撸码那些事(lumanxs)

原文发表时间:2018-05-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏王亚昌的专栏

让代码更有效率的方法

        老大总结的代码级提高代码执行效率需要注意的点,很值得和大家分享一下,在这儿也由衷地感谢下老大的总结和工作中的指导。大多数的点都在项目中验证过,比...

831
来自专栏程序人生

如何愉快地写个小parser

(一) 在前几日的文章『软件随想录』里,我随性写了一句:「现在似乎已经不是lex/yacc 或 bison/flex的时代了。我亲眼看见一个同事在费力地用per...

5819
来自专栏Java技术栈

6 道 BATJ 必考的 Java 面试题

请对比 Exception 和 Error,另外,运行时异常与一般异常有什么区别?

1121
来自专栏PHP在线

PHP 代码规范简洁之道

原文出处: Scholer 1. 统一的编码规范 编码规范往简单说其实就是三个方面: 换行 空格 变量命名 放在 PHP 里面,还有一些附加的地方,比如关键字...

4136
来自专栏算法与数据结构

PTA 数据结构 银行业务队列简单模拟

仅供参考,请勿粘贴 设某银行有A、B两个业务窗口,且处理业务的速度不一样,其中A窗口处理速度是B窗口的2倍 —— 即当A窗口每处理完2个顾客时,B窗口处理完1个...

2158
来自专栏微信公众号:Java团长

Java基础05 实施接口

在Java基础04 封装与接口中,private关键字封装了对象的内部成员。经过封装,产品隐藏了内部细节,只提供给用户接口(interface)。

912
来自专栏landv

我的第一个Java程序和Java简介

1302
来自专栏Java学习网

Java虚拟机工作原理之JVM用到的3大计算机核心功能,重点是方法调用

JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模...

2033
来自专栏韩伟的专栏

框架设计原则和规范(一)

此文是《.NET:框架设计原则、规范》的读书笔记,本文内容较多,共分九章,将分4天进行推送,今天推送1-3章。 1. 什么是好的框架 2. 框架设计...

4575
来自专栏代码世界

6大设计原则总结

6大设计原则总结 一、单一职责原则  单一职责原则:英文名称是Single Responsiblity Principle,简称是SRP。定义:应该有且仅有一个...

2959

扫码关注云+社区

领取腾讯云代金券