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

抽象型坏味

不完整的抽象

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

为什么要有完整的抽象?

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

一些常见的互补方法对

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

参考:《软件设计重构》

作者:撸码那些事

声明:本文为博主学习感悟总结,水平有限,如果不当,欢迎指正。如果您认为还不错,不妨关注一下下方的微信公众号【撸码那些事】,获取最新更新,谢谢支持。转载与引用请注明出处。

微信公众号:

关注微信公众号,获取最新更新

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏思考的代码世界

Python网络数据采集之数据清洗|第06天

1393
来自专栏iOS 开发

iOS 代码使用 C++ 的 zero-cost abstraction 特性

1973
来自专栏人工智能LeadAI

python与数据科学应用

数据科学简介与应用 数据科学主要以统计学、机器学习、数据可视化以及(某一)领域知识为理论基础,其主要研究内容包括数据科学基础理论、数据预处理、数据计算和数据管...

3745
来自专栏spring源码深度学习

java核心技术——Exception和Error的区别

Exception 和 Error 都是继承了 Throwable 类,在 Java 中只有 Throwable 类型的实例才可以被抛出(throw)或者...

1651
来自专栏HansBug's Lab

算法模板——Dinic网络最大流 1

实现功能:同sap网络最大流 今天第一次学Dinic,感觉最大的特点就是——相当的白话,相当的容易懂,而且丝毫不影响复杂度,顶多也就是代码长个几行 主要原理就是...

3088
来自专栏张善友的专栏

读《代码不朽:编写可维护软件的10大要则》C# 版

这本书特别针对没有接受过计算机科学或软件工程专业学习的软件开发人员,这类人员除了熟悉所用语言语法和语义之外,很少接受其他专业培训,对软件工程中的一些概念理解欠缺...

6720
来自专栏炉边夜话

调查问卷:测试你对多核多线程的认知程度

        目前,多核多线程编程已经成为一种趋势,但大部分程序员还没有从串行程序的思维中走出来。即使有些人对多核多线程的概念有所了解,但也是一知半解,...

1322
来自专栏前端黑板报

Vue列表循环从指定下标开始

最近遇到一个问题,在循环商品列表时,因为数组的第一个是商品的品牌介绍,所以循环时不能直接循环,只能从第二个元素开始。

1.3K3
来自专栏决胜机器学习

设计模式专题(十八) ——桥接模式

设计模式专题(十八)——桥接模式 (原创内容,转载请注明来源,谢谢) 一、概述 桥接模式(Bridge)将抽象部分与实现部分分离,使每一部分之间互相独立化,使...

3748
来自专栏韩伟的专栏

面向对象的代码风格(上)

大家过年好呀!公众号从今天开始恢复更新,感谢大家不离不弃的关注。 今天的文末有投票,以助于我在新的一年里将公众号做得更好,踊跃参加一下吧! 本篇文章分两章发送,...

3998

扫码关注云+社区

领取腾讯云代金券