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

不完整的抽象

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

为什么要有完整的抽象?

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

一些常见的互补方法对

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一日一条

优秀的Java程序测试是什么样的?

测试的名字至关重要,特别是从文档角度来看的话。我们应该能够大声读出测试的名字就像一组需求一样。事实上,有一个伟大的IntelliJ插件,叫Enso,它会将你的测...

442
来自专栏区块链大本营

为将傅恒与魏璎珞的爱情上链,作为技术小白的我读了EVM上百行代码,终于搞定了

延禧攻略最近大火,傅恒和魏璎珞求而不得的爱情也令很多人觉得惋惜。那么傅恒到底为什么爱上魏璎珞呢?有网友真相了。

1053
来自专栏Golang语言社区

Go程序GC优化经验分享

最近一段时间对《仙侠道》的服务端进行了一系列针对GC的调优,这里跟各位分享一下调优的经验。

1744
来自专栏撸码那些事

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

一种重要的抽象实现手法是创建内聚而完整的抽象。抽象未支持相关的方法时,可能会影响抽象的内聚性和完整性。如果抽象只支持部分相关的方法,其使用者就可能不得不自己去实...

1639
来自专栏大内老A

WCF技术剖析之二十二: 深入剖析WCF底层异常处理框架实现原理[上篇]

对于上一篇文章 (WCF基本异常处理模式:[上篇]、[中篇]、[下篇]),主要是站在最终开发者的角度对WCF关于异常处理编程模式进行了介绍,接下来,我们需要将我...

1819
来自专栏Java学习网

Java细粒度锁实现的3种方式

Java细粒度锁实现的3种方式 最近在工作上碰见了一些高并发的场景需要加锁来保证业务逻辑的正确性,并且要求加锁后性能不能受到太大的影响。初步的想法是通过数据的时...

2839
来自专栏ml

C++ 与设计模式学习(其一)

       记得曾经一年前,听到同学再说设计模式,当时觉得不怎么重要,所以就没有去系统的学习,这一放,就是一年,直到前段时间,面试了一个阿里巴巴的职位,要我谈...

3637
来自专栏

消失的魔术:隐藏在js引用和原型链背后的超级能力

js这门语言有很多诟病,然而很多被无视的点,构成了js最为美妙的语言特性。这篇文章将带你走进魔术般的引用型数据类型和原型链背后,寻找那些被遗忘的超能力。并且,基...

832
来自专栏架构师之旅

轻松学习设计模式之面向对象的设计原则

对于面向对象软件系统的设计而言,在支持可维护性的同时,提高系统的可复用性是一个至关重要的问题,如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决...

793
来自专栏斑斓

代码诊所的第二次诊断

几年前,我有机会负责一个项目的咨询。团队很小,目标是对旧有系统的后端用Java改写,而团队的开发人员全为C程序员。我的工作职责是负责项目设计、开发,以及担任项目...

3455

扫码关注云+社区