目录
前言
在软件领域中，最先诞生的是软件模式，软件模式(Software Patterns)是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件开发生命周期的每一个阶段都存在着一些被认同的模式。
软件模式是在软件开发中某些可重现问题的一些有效解决方法，软件模式的基础结构主要由四部分构成，包括问题描述【待解决的问题是什么】、前提条件【在何种环境或约束条件下使用】、解法【如何解决】和效果【有哪些优缺点】
在软件模式中，设计模式是研究最为深入的分支，设计模式用于在特定的条件下为一些重复出现的软件设计问题提供合理的、有效的解决方案，它融合了众多专家的设计经验，已经在成千上万的软件中得以应用。设计模式其实就是一种软件设计的整体思路。就是要把一些东西抽象出来再通过一定的方式重新整理，从而达到合理优化。这么说不好理解，就举个例子把。比如你最初只是建造了一座房子，只有四面墙一个顶。可随着你的需求增多，你要不断的装修这个房子。这里添面墙，那里掏个洞的。最终有一天你会发现你的装修没有一个合理的规划，导致了好好的一个房子弄的跟个迷宫似得。软件设计也是这样，如果最初就没有一个设计模型，只是为了完成功能而写代码。最终这个程序会混乱不堪。
而设计模式中每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心，这样，你就能一次又一次地使用该方案而不必做重复劳动。这个思想运用于面向对象的设计模式，核心就在于提供给了相关问题的解决方案。
设计模式的类型
虽然GOF设计模式只有23个，但是它们各具特色，每个模式都为某一个可重复的设计问题提供了一套解决方案。根据它们的用途，这些模式可以分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。
创建型模式：对象实例化的模式，创建型模式用于解耦对象的实例化过程。
结构型模式：把类或对象结合在一起形成一个更大的结构。
行为型模式：类和对象如何交互，及划分责任和算法。
在GOF 23种设计模式中包含5种创建型设计模式、7种结构型设计模式和11种行为型设计模式。
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
设计模式的特点
那设计模式又是如何解决设计问题的呢？
1、寻找合适的对象
面向对象程序由对象组成，对象包括了数据和对数据进行操作的过程，过程称为方法或操作。对象收到客户的请求后，执行相应的操作。其中面向对象设计最困难的部分就是如何将系统分解成对象集合。
2、决定对象的粒度
描述了我们应该决定一个对象应该是什么？
3、指定对象的接口
对象生命的每一个操作指定操作名、作为参数的对象(入参)和返回值，这就是所谓的操作结构。对象接口描述了该对象所能接受的全部请求的集合，任何匹配对象接口中的结构请求都可以发送给该对象。
在面向对象系统中，接口是基本的组成部分。对象只有通过他们的接口才能与外部交流。对象接口与其功能实现是分离的，不同对象可以请求做不同的实现，也就是说，两个有相同接口的对象可以有完全不同的实现。
4、描述对象的实现
针对接口编程，而不是针对实现编程
业务中落地
在实际工作中也有着很多的使用场景。比较常见的一个场景就是替换if-else。在开发过程中，很多时候会遇到switch或者if-else的判断。这种方式写出来的代码其实是违背了开闭原则，在增加新类型的时候需要在switch或者if-else里面增加判断，很可能原逻辑修改代码出现不可预料性灾难。下面将分别介绍供应链业务中两种场景所使用到的设计模式。
房源上房处理链业务-责任链模式
为了使上房流程优化、校验模型抽象，更易于模型的可扩展性和复用性，解决研发过程中的速度、成本、质量、风险问题，抽象出校验模型。具体设计结构如下：
整体结构设计用例图
抽象责任链UML类图
责任链注册中心UML类图
自动追价优惠活动策略处理器业务-策略模式
为了适应不断新增的活动策略的使用场景，将优惠活动处理策略模型抽象化。具体设计结构如下：
整体结构设计用例图
策略模型UML类图：不同的优惠策略，只需要继承同一个抽象接口即可。每个优惠策略相互独立、互不影响。
策略注册工厂UML类图：初始化生产和调用策略模型工厂，将策略模型在项目启动时候初始化创建
调用结构用例图：使用的时候根据策略类型取出对应的策略模型使用即可，无需判断
日志工厂对象处理业务-单例模式
另外一个业务场景就是打印日志的时候，确保日志相关类只有一个实例，而且自行实例化并向整个系统提供这个实例。
整体结构设计用例图-饿汉式
核心代码
public class ProductPriceLogFactory{
private static final ProductPriceLogFactory INSTANCE = new ProductPriceLogFactory();
public static ProductPriceLogFactory getInstance() {
return INSTANCE;
}
}多种场景打印封装日志业务-抽象工厂模式
整体结构设计用例图
基础日志工厂，提供一个抽象接口以及通用日志对象。针对不同场景只需要创建场景工厂，实现抽象方法完成自身场景的业务逻辑。
日志工厂UML类图
结语
设计模式对于会用的人来说很实用，对不理解的人来说很鸡肋。一个功能实现方式可以五花八门，久经考验的设计模式也只是提供一些参考。硬套模式、为模式而模式这类行为很2。不莽撞、不刻意也显得非常重要。
在文章的结尾稍微做个正式点的总结：
1、设计模式，是一系列思想抽象，它告诉开发人员在某一类场景有哪些最佳实践，也能为以后的代码架构设计提供重要的参考。
2、模式不是银弹，不要一切皆模式，一个简单的方法能搞定，就没有必要多建几个类和模型。抽象业务场景才是设计模式的核心。
1936
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
