抽象原则倡导通过精简和概括来简化实体:精简是删除不必要的细节,而概括是找出并定义通用的的重要特征。
这是什么?
这是一个笑脸,那么我们是怎么知道这是一个笑脸的呢?通过抽象。人脸数以亿计,却各不相同。我们忽略了不重要的细节,如发型和发色。我们还概括了相同的东西,每个人都有两只眼睛,微笑时嘴角上扬。这就是抽象。对于软件工程师来说,抽象能力是最重要的能力之一,也恰恰是最难得的能力之一。
应用抽象原则的实现手法
-
提供清晰的概念边界和唯一身份
每个抽象都必须有清晰而明确的概念边界,还必须有身份。例如,不传递一组表示日期、矩形坐标或图片属性的数据值,而是在代码中分别为日期、矩形坐标或图片属性创建抽象。
-
映射域实体
必须创建从问题域到解决方案域的词汇映射,即对于问题域中的对象,必须在解决方案域中使用相应的抽象来表示它们。
-
确保内聚性和完整性
抽象必须对其承担的职责提供全面支持。例如表示组合框的类支持禁用或隐藏特定的元素,就必须同时支持启用或显示这些元素的选项。如果只提供方法的一部分,抽象既不内聚也不完整。
-
赋予单一而重要的职责
确保每个抽象都分配单一而重要的职责。
单一:每个抽象都应该只负责一件或一类事情。
重要:抽象不能太鸡肋。
-
避免重复
确保每个抽象(名称和实现)只在设计中出现一次。重复的名称将会给设计的使用者带来困惑,重复的实现将会增加维护负担,因为需要维护多块相同的代码。
违反抽象原则导致的坏味
我们这篇博客主要讲解分析缺失抽象坏味,对于其它抽象坏味将在后面的博客讲解分析。
缺失抽象
使用一系列数据或编码字符串,而不创建类或接口时,将引发这种坏味。
为什么不能缺失抽象?
通常,由于缺失抽象,相关的数据和行为将会分散在其它抽象中,这将会导致两个问题l:
- 可能会向其它抽象暴露实现细节,违反封装原则
- 数据和相关的行为分散在不同的抽象中,可能导致实体之间高度耦合,结果是代码脆弱且难以重用。因此,不创建必要的抽象也违反了模块化原则。
缺失抽象潜在的原因
未做充分的设计分析
没有经过充分的设计分析,很容易就会忽略创建抽象,而使用基本数据类型来完成任务。
未重构
随着需求的变化和软件的发展,原来使用的基本数据类型可能需要重构为使用类或接口。
错误地将重点放在细微的性能改善上
例如直接使用数组,而不创建合适的抽象。这种“优化”带来的性能改善都很有限,不值得为此牺牲设计质量。
示例分析一
在一个图书馆信息管理程序中,ISBN(国际标准书号)的存储和处理十分重要,可以使用字符串类型进行存储,但是这种选择很糟糕。ISBN(国际标准书号)有两种表示方式:10位和13位。图书馆信息管理程序逻辑包含ISBN的接受、验证、处理和转换。如果使用基本的字符串类型存储ISBN,处理的逻辑将会分散在很多地方,实体之间高度耦合,代码脆弱且难以重用。
正确的方案是:创建一个抽象类或接口ISBN,其中包含通用的操作。并创建子类ISBN-10和ISBN-13,它们都扩展超类ISBN。
示例分析二
应用程序中常常包含总是同时使用的基本数据类型,通常情况下这些“数据泥团”就意味着缺失抽象。例如在绘画程序中确定一个二维的点的位置,通常比较差的做法可能会用(double x,double y)。重构的建议是将必不可少的字段提取到一个新类(Rectangle)中,并且将操作这些字段的方法移到这个类中。
public class Rectangle
{
/// <summary>
/// 横坐标
/// </summary>
private int x;
/// <summary>
/// 纵坐标
/// </summary>
private int y;
public Rectangle(int x,int y)
{
this.x = x;
this.y = y;
}
public void Draw()
{
//绘制(x,y)
}
}
现实考虑
有时候,实体只是数据元素,没有任何相关联的行为。在这种情况下,使用类或接口来表示它们可能导致过度设计,增加了设计的复杂性。因为在创建抽象前,一定要根据应用抽象具体情况分析,再决定是否要创建抽象。
参考:《软件设计重构》
Java实现文件分割和文件合并实例
dotweb——go语言的一个微型web框架(三)路由注册
dotweb——go语言的一个微型web框架(二)启动dotweb
dotweb——go语言的一个微型web框架(一)
Linq的查询操作符
dsfgdfg
.NET Entity Framework (with Oracle ODP.NET) -Code First
.NET Entity Framework (with Oracle ODP.NET)
ODP.NET 之 ExecuteNoQuery 执行 Merge into 返回值