设计特性思考

平时的开发中避免不了技术设计，那么在设计中，我们怎么评判设计是否是优良的呢？

理想中的设计特性

1. 最小复杂度

怎么理解最小复杂度呢？
个人理解：设计的目标就是让复杂度最小化，要避免作出“聪明的”设计，“聪明的”设计往往难以理解。如果你的设计方案不能让你专注于某一部分，那么这一设计就没有什么作用了。

比如说我们有一个main方法，我们将过程代码拆分为多个方法，方法一专注A事项，方法二专注B事项。最简单的案例：

public static void main(String args){
	//专门用来新增A表数据
	this.saveA();
	//专门用来删除B数据
	this.removeB();
}

public static void saveA(){}

public static void removeB(){}

2. 易于维护

易于维护意味着陈故乡设计时为维护的程序员着想。请时刻想着这些维护程序员可能面对你写的代码提出的问题，把这些程序员当作你的听众，设计出自明的系统！

通俗来讲尽量让你代码可读性更高，避免当别人看到你代码根本不想往里面继续看。

比如说一个 DTO 类一堆的属性，看着完全没有可读性，完全不知道哪些我需要用哪些我不需要用，可维护性极低。
再比如说一个方法里面一堆 if 毫无注释，再加上一些看起来很高大上的 stream 处理。看着让人懵逼的不行，抗拒维护此类代码。

3. 松散耦合

松散耦合意味着相互联系却又彼此保持独立。通过应用类接口中的合理抽象、封装性以及信息隐藏等设计出相互关联尽可能最少的类，减少关联也就减少了集成、测试与维护时工作量。

4. 可扩展性

开闭原则！

可扩展性是指你能增强系统的功能而无需改动底层结构，你可以改动系统的某一部分而不影响其他部分。

5. 可重用性

你的代码是否可重复使用？代码是否能抽离？
比如说查询用户列表，提供一个 service 是否能够设计大家通用？

比如说获取 IP 的方法 放在 util 类中

6. 高扇入

高扇入指的是让大量的类使用某个给定的类。

比如说一些工具类（utility classes）

比如说一个业务中通用的获取逻辑，比如规则引擎，获取规则数据。

7. 低扇出

低扇出是指一个类少量或适中的使用其他的类。高扇出（超过约7个）说明一个类使用了大量其他的类，因此可能变得过于复杂。

可以想象一下，一个类中引入了一堆 service 看着就头大。一个类中上百行代码只是为了引入其他类！灾难啊！

8. 可移植性

是否能够很方便的移植到其他环境中呢？

比如说框架的骨架能否抽离？放到别的环境是否试用？ 当然一般我们的业务代码其实很难做到～

9. 精简性

精简意味着设计出的系统没有多余的部分。
伏尔泰曾说，一本书的完成，不在于它不能在加入任何内容的时候，而在不能删去任何内容的时候。在软件领域中，这一观点就更正确了。因任何多余的代码也需要开发、复审、测试，并且当修改其他代码之后还需要重复的考虑它们。软件后续的版本也要和这些多余代码保持向后兼容。要问这个关键问题：“这虽然简单，但把它加入进来后会损害什么呢”

10. 层次性

层次性意味着尽量保持各个系统的层次性，使你能在任意层面上观察系统，并得到某种具有一致性的看法。

比如说你在基于一个旧系统写新逻辑。应该设计一个同旧代码交互的层。在设计这一层时它应该能够隐藏旧代码的低劣质量，同时为新的层次提供一组一致的服务。这样系统的其他部分就只需与这一层进行交互，无须同系统旧代码打交道了。

11. 标准技术

一个系统所依赖的外来的、古怪的越多，别人在第一次见到的时候就越头疼。要尽量使用标准化的实现方式，让整个系统给人一种熟悉的感觉。

---

在我们写完伪代码设计完时，在回头来看看理想的设计，是否能够满足呢？

设计时也要记得基于理想的设计来出方案哦～