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

不完整的抽象

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

为什么要有完整的抽象?

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

一些常见的互补方法对

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 条评论
登录 后参与评论

相关文章

来自专栏java一日一条

程序中减少使用if语句的方法集锦

大约十年前,我听说了反if的活动,觉得这个概念非常荒谬。如果不用if语句,又怎么能写出有用的程序呢?这简直太荒谬了。

1242
来自专栏Vamei实验室

Java基础05 实施接口

在封装与接口中,private关键字封装了对象的内部成员。经过封装,产品隐藏了内部细节,只提供给用户接口(interface)。 接口是非常有用的概念,可以辅助...

2067
来自专栏我是攻城师

为什么用 Java:一个 Python 程序员告诉你

3529
来自专栏王亚昌的专栏

让代码更有效率的方法

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

681
来自专栏landv

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

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

Java基础05 实施接口

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

742
来自专栏代码世界

6大设计原则总结

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

2779
来自专栏Java技术栈

6 道 BATJ 必考的 Java 面试题

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

971
来自专栏Java编程

Java回调机制解读

在一个应用系统中,无论使用何种语言开发,必然存在模块之间的调用,调用的方式分为几种:

2846
来自专栏马洪彪

spss C# 二次开发 学习笔记(二)——Spss以及统计术语解释(IT人眼中的统计术语)

针对客户需求,需要对一些数据做统计分析。统计分析的第一步,即为数据查询,查找出要统计分析的数据。 查询得出的是一个行列表格的结果集,行、列、表格等这些IT的数据...

2735

扫码关注云+社区