1.摘要

一款软件产品好不好用, 除了拥有丰富的功能和人性化的界面设计之外, 还有其深厚的底层基础, 而设计模式和算法是构建这个底层基础的基石。好的设计模式能够让产品开发快速迭代且稳定可靠, 迅速抢占市场先机；而好的算法能够让产品具有核心价值, 例如字节跳动公司旗下的抖音、今日头条等众多产品以算法起家, 能够智能根据用户喜好精准推送其感兴趣的内容。在本章节中, 将对软件设计模式的相关知识进行总结, 为后面的学习打下基础。

2.设计模式简介

软件设计模式是指在软件开发过程中, 经过验证的, 用于解决在特定环境中重复出现的特定问题解决方案。可以将设计模式想象成根据需求进行调整的预制蓝图, 可用于解决代码中反复出现的设计问题。

设计模式与方法或库的使用方式不同, 很难直接在自己的程序中套用某个设计模式。模式并不是一段特定的代码, 而是解决特定问题的一般性概念。每一个程序员都可以根据模式来实现符合自己程序实际所需的解决方案。

2.1 为什么需要设计模式

优秀的开发者身上总蕴藏着一股力量, 阅读他们写的代码的最直观感受就是代码可重用性高、可读性强、灵活性好、可维护性强等特点。这些优秀的开发者实际上遵循的是他们自己的一套不断完善和总结的解决方案, 而设计模式实际上是根据以前的实践和经验记录要采用的解决方案, 在设计模式的实现过程中, 需要使用多个软件组件共同实现某些功能。因此, 设计模式加快了涉及多个组件的开发过程。开发者可以在对应解决方案的具体应用中使用自己熟悉的编程语言。

设计模式提供了经过验证的开发范例, 有助于节省时间, 而不必在每次出现问题时都重新创建设计模式。设计模式使程序设计更加标准化、代码编写更加工程化,从而提高软件的开发效率, 缩短软件的开发周期。

2.2 设计模式的发明者

在1994年, Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides四人合著出版了<<设计模式-可复用面向对象软件的基础>>一书, 将设计模式的概念应用到程序开发领域中, 该书提供了23个模式来解决面向对象程序设计中的各种问题, 很快便成为了畅销书。由于书名太长, 人们将其简称为"四人组(Gang of Four, GoF)的书",并且很快进一步简化为''GoF的书"。

这些设计模式总共可以分为三大类: 创建型设计模式(Creational Patterns)、结构型设计模式(Structural Patterns)、行为型设计模式(Behavioral Patterns)。随着设计模式的不断发展, 设计模式的种类有所增加, 新增了空对象模式(Null Object Pattern)、规格模式(Specification)等。

2.3 怎样使用设计模式

在软件开发过程中, 开发者通常会基于业务需求选择设计模式, 在使用设计模式前, 开发者需要明白技术的目的是为业务而服务, 技术只是满足业务的一个工具, 如果开发者掌握了每种设计模式的应用场景、特征、优点和缺点, 以及不同设计模式的关联关系, 就可以很好的使用设计模式满足日常业务的需要。

2.3.1 需求驱动

在使用设计模式进行软件开发时, 应尽量按照特定需求进行综合分析和权衡。需求驱动应综合考虑软件的可维护性、可复用性等因素, 既要考虑开发效率, 又要考虑后期维护的便利性和复杂性。此外, 设计模式要根据具体项目进行评估, 如果某个项目没有应用场景, 则不一定需要设计模式。

2.3.2 对开发语言特性了解

设计模式在不同语言中的具体实现方式可能有所不同, 要根据具体的开发语言进行实现。例如:与Java、C++不同, Go语言中没有继承, 所以Go语言的设计模式具体实现方式与Java、C++使用的设计模式具体实现方式不同。

2.3.3 积累设计模式经验

学习编程的快速方法是进行实战, 学习设计模式也是如此, 在进行软件开发过程中多问问自己, 为什么要这样使用设计模式? 为什么要使用这个设计模式? 一定要使用这个设计模式吗?

2.3.4 避免设计过度

设计模式解决的是软件设计不科学问题, 但是在实战开发过程中, 容易出现设计过度问题。在设计模式的实战开发过程中, 核心原则是保持简洁, 设计模式的目的是使软件的设计及维护更加简单, 而不是更加复杂。

3.优秀设计特征

3.1 代码复用

无论是开发何种软件产品, 成本和时间都是重要的两个维度, 较短的开发时间意味着可比竞争对手更早进入市场, 抢占市场先机; 而较低的开发成本意味着能够留出更多营销资金, 因此能更广泛的覆盖潜在客户。

代码复用是减少开发成本时最常用的方式之一。其意图非常明显: 与其反复从头开发, 不如在新对象中重用已有代码。这个想法虽然可以, 但实际上要让已有代码在全新的上下文工作, 通常还是需要付出额外努力的。组件之间紧密的耦合、对具体类而非接口的依赖和硬编码的行为都会降低代码的灵活性, 使得复用这些代码变得更加困难。

使用设计模式是增加软件组件灵活性并使其易于复用的方式之一, 但有时, 这也会让组件变得更加复杂, 有时候不得不从底层、中间层和框架之间寻找平衡点, 因此一个好的代码复用解决方案总是从实践当中不断总结, 而不是生搬硬套设计模式。

3.2 扩展性

程序员生命中唯一不变的事情就是适应变化。

从程序员自身角度, 经常会遇到潜在变化的需求, 例如:

• 在Windows平台上发布了一款应用, 但受众人群也想要macos平台的版本。

• 我们创建了一个使用方形按钮的GUI框架, 但几个月之后圆形半透明按钮开始流行起来。

• 设计了一款优秀的电子商务网站架构, 但仅仅几个月之后, 客户要求新增接受电话订单的功能。

相信每个开发者都在经历相似的事情, 为了适应变化, 我们会不断的优化代码结构, 评估现有的技术框架, 甚至给代码质量制定标准。最终目的是让自己的代码能够在不做大量更改的同时, 能够方便加入新的需求功能。

4.设计模式原则

在前人的基础上, 已经总结出一些公认的通用设计原则, 这里做个简单介绍, 后面的章节会详细展开。

4.1 单一职责原则

单一职责原则(Single Responsibility Principle)的主要目的是减少复杂度, 我们不需要费尽心机去构思如何使用200行代码来实现一个复杂设计, 实际上完全可以使用十几个清晰的方法。

当程序规模不断扩大、变更不断增加后, 真实问题才会逐渐显现出来, 到某个阶段, 相应的代码会变得过于庞大, 以至于无法记住所有细节,查找代码变得异常缓慢, 必须浏览整个类, 甚至整个工程才能找到需要的东西。如果开始感到对代码逐步失去控制, 应该回忆一下单一职责原则, 将某些类进行拆分, 尽量让一个类只做一件事情。

4.2 开闭原则

开闭原则(Open/Closed Principle)是指对扩展开放, 对修改关闭。在程序需要进行扩展时, 不能修改原有的代码, 实现一个热插拔效果, 从而使程序的扩展性更好,易于维护和升级。要达到这样的效果, 开发者需要使用接口和抽象类。

4.3 里氏替换原则

里氏替换原则(Liskov Substitution Principle)是面向对象设计的基本原则之一。里氏替换原则告诉我们, 任何基类可以出现的地方, 子类一定会出现。里氏替换原则是继承复用的基石, 只有当子类可以替换基类且软件组件的功能不受影响时, 基类才能真正被复用, 使子类能够在基类的基础上增加新的行为。里氏替换原则是对开闭原则的补充, 实现开闭原则的关键步骤是抽象化, 而基类与子类的继承关系是抽象化的具体实现, 所以里氏替换原则是对实现抽象化的具体步骤的规范。

4.4 依赖倒置原则

依赖倒置原则(Dependency Inversion Principle)是指在设计代码架构时, 高层模块不应该依赖底层模块, 二者都应该依赖于抽象, 抽象不应该依赖于细节, 细节应该依赖于抽象。

依赖倒置原则好处:

• 减少类之间的耦合性,提高系统的稳定性。

• 降低并行开发引起的风险。

• 提高代码的可读性和可维护性。

4.5 接口隔离原则

接口隔离原则(Interface Segregation Principle)是指使用多个隔离接口比使用单个隔离接口要好, 它的另一个含义是降低类之间的耦合度, 由此可见, 设计模式就是从大型软件架构出发, 便于升级和维护的软件设计思想, 它强调减少依赖, 降低耦合度。

4.6 迪米特法则

迪米特法则(Law of Demeter)又叫最少知识原则, 也就是说, 一个对象应当对其它对象尽可能少的了解。迪米特法则的目的在于降低类之间的耦合性, 由于每个类尽量减少对其它类的依赖, 因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。

4.7 合成复用原则

合成复用原则(Composite/Aggregate Reuse Principle, CARP)是指尽量使用对象组合(has-a)/聚合(contanis-a),而不是继承关系达到软件复用的目的, 可以使系统更加灵活, 降低类与类之间的耦合度, 一个类的变化对其它类造成的影响相对较少。

5.总结

在本章节中, 我们学习了设计模式的概念和使用方式, 总结了设计模式的7大原则, 通过对设计模式原则的了解, 大致可以清楚在平时开发项目中需要注意的一些设计问题, 然而真正在项目应用的设计模式至少有23个, 这几十个设计模式大致可以归为三大类: 创建型设计模式、结构型设计模式和行为型设计模式, 在后面的学习分享中会逐步展开。