简介： 设计模式可能帮忙咱们优化代码构造，让代码更优雅灵便。有哪些常见的设计模式？如何正当使用？本文分享作者对工厂模式、单例模式、装璜模式、策略模式、代理模式和观察者模式的了解，介绍每种模式的模式构造、优缺点、实用场景、留神实现及代码实现。
一 前言
最近在革新一些历史的代码，发现一个很显著的特点，大部分代码是记叙文，依照事件的倒退过程将故事平淡无奇的解说进去。
这种形式的益处是比拟合乎人类的思维习惯，一条主线讲到底，代码浏览起来没有太大难度，只有顺着藤就能摸到瓜，然而毛病也很显著，一旦故事线中须要插入一些新的元素，比方：退出一个新的人物角色、新的工夫线，都会须要大量更改故事线以配合这个新元素的融入，甚至对原有文章造成破坏性的影响。
为了解决这个问题，人们总结出了很多种文章构造，例如：总-分构造，并列结构，总-分-总构造等等，有了这些构造，在退出新元素的时候，甚至不用思考新元素与原故事情节的关联性，间接单拉一个分支故事线独立去讲就好了，只有可能在整体故事完结前，与汇聚到主线故事就能够了（是不是很像git？）。
在软件开发畛域，也有很多这样的十分有用的实际总结，咱们称之为设计模式。对于设计模式，大家都不生疏，轻易找集体，预计都能讲出N个设计模式来，然而除了这些设计模式的概念，很多人不晓得如何灵活运用这些设计模式。所以借这篇文章和大家独特学习设计模式的思维。
二 了解设计模式
我尽量用最通俗易懂的示例和语言来讲述我了解的设计模式，心愿能对大家有所帮忙。
另外也无需精通所有的设计模式，只有可能融汇贯通常见的设计模式，就能让你的代码变得优雅。就像程咬金只会三板斧，然而熟练度无人能及，照样能横行天下。
1 工厂模式(Factory)
简略工厂(Simple Factory)
小明追妹子的时候，请她喝了不少咖啡，她爱喝卡布奇诺，每次去咖啡店，只有跟服务员说“来杯卡布奇诺”就行了，尽管各家的口味有些不同，然而不论是星爸爸还是Costa，都可能提供卡布奇诺这种咖啡。这里的星爸爸和Costa就是生产咖啡的工厂。
（1）简略工厂模式构造
简略工厂模式蕴含如下角色：
- Factory：工厂角色-负责实现创立所有实例的外部逻辑.
- Product：形象产品角色-是所创立的所有对象的父类，负责形容所有实例所共有的公共接口。
- ConcreteProduct：具体产品角色-是创立指标，所有创立的对象都充当这个角色的某个具体类的实例。
结构图：
时序图：
（2）优缺点
- 长处：客户类和工厂类离开。消费者任何时候须要某种产品，只需向工厂申请即可。消费者毋庸批改就能够接收新产品。
- 毛病：是当产品批改时，工厂类也要做相应的批改。
工厂办法(Factory Method)
以前常常带老婆去优衣库（简略工厂）买衣服，就那么多样式，逛的次数多了，她就烦了。起初我扭转策略，带老婆去逛商场（形象工厂），商场里有各式品牌的店铺，不必我管，她本人就能逛上一整天。
区别于简略工厂，外围工厂类（商场）不再负责所有产品的创立，而是将具体创立的工作交给子类（服装店）去做，成为一个形象工厂角色，仅负责给出具体工厂类必须实现的接口（门店），而不接触哪一个产品类该当被实例化这种细节。
（1）工厂办法模式构造
工厂办法模式蕴含如下角色：
- Product：形象产品
- ConcreteProduct：具体产品
- Factory：形象工厂
- ConcreteFactory：具体工厂
结构图：
时序图：
工厂模式总结
（1）实用场景
输入的产品是规范品，谁来做都能够。
（2）举例
常见的数据库连贯工厂，SqlSessionFactory，产品是一个数据库连贯，至于是oracle提供的，还是mysql提供的，我并不需要关怀，因为都能让我通过sql来操作数据。
（3）注意事项
我的项目初期，软件结构和需要都没有稳定下来时，不倡议应用此模式，因为其劣势也很显著，减少了代码的复杂度，减少了调用档次，减少了内存累赘。所以要留神避免模式的滥用。
（4）简略实现
package FactoryMethod;public class FactoryPattern { public static void main(String[] args) { Factory factory = new ConcreteFactoryA(); Product product = factory.createProduct(); product.use(); }}_//形象产品：提供了产品的接口_interface Product { public void use;}_//具体产品A：实现形象产品中的形象办法_class ConcreteProductA implements Product { public void use() { System.out.println("具体产品A显示..."); }}_//具体产品B：实现形象产品中的形象办法_class ConcreteProductB implements Product { public void use() { System.out.println("具体产品B显示..."); }}_//形象工厂：提供了厂品的生成办法_interface Factory { public Product createProduct();}_//具体工厂A：实现了厂品的生成办法_class ConcreteFactoryA implements AbstractFactory { public Product createProduct() { System.out.println("具体工厂A生成-->具体产品A."); return new ConcreteProductA(); }}_//具体工厂B：实现了厂品的生成办法_class ConcreteFactoryB implements AbstractFactory { public Product createProduct() { System.out.println("具体工厂B生成-->具体产品B."); return new ConcreteProductB(); }} 2 单例模式(Singleton)
韦小宝有7个老婆，然而每个都只有他这一个老公，他的所有老婆叫老公时，指的都是他，他就是一个单例。
单例模式构造
单例模式蕴含如下角色：
- Singleton：单例
结构图：
时序图：
优缺点
- 长处：全局只有一个实例，便于对立管制，同时缩小了系统资源开销。
- 毛病：没有形象层，扩大艰难。
利用场景
适宜须要做全局对立管制的场景，例如：全局惟一的编码生成器。
注意事项
只对外提供公共的getInstance办法，不提供任何公共构造函数。
简略实现
public class Singleton{ private static volatile Singleton instance=null; //保障 instance 在所有线程中同步 private Singleton(){} //private 防止类在内部被实例化 public static synchronized Singleton getInstance(){ //getInstance 办法前加同步 if(instance == null) { instance = new Singleton(); } return instance; }} 3 装璜模式(Decorator)
大学毕业，想要送给室友一个有留念意义的礼物，就找到一张大家的合照，在下面写上“永远的兄弟！”，而后拿去礼品店装了个相框，再包上礼盒。这里的我和礼品店都是装璜器，都没有扭转照片自身，却都让照片变得更适宜作为礼物送人。
装璜模式构造
装璜模式蕴含如下角色：
- Component：形象构件
- ConcreteComponent：具体构件
- Decorator：形象装璜类
- ConcreteDecorator：具体装璜类
结构图：
时序图：
优缺点
- 长处：比继承更加灵便（继承是耦合度很大的动态关系），能够动静的为对象减少职责，能够通过应用不同的装璜器组合为对象扩大N个新性能，而不会影响到对象自身。
- 毛病：当一个对象的装璜器过多时，会产生很多的装璜类小对象和装璜组合策略，减少零碎复杂度，减少代码的浏览了解老本。
实用场景
- 适宜须要（通过配置，如：diamond）来动静增减对象性能的场景。
- 适宜一个对象须要N种性能排列组合的场景（如果用继承，会使子类数量爆炸式增长）
注意事项
- 一个装璜类的接口必须与被装璜类的接口放弃雷同，对于客户端来说无论是装璜之前的对象还是装璜之后的对象都能够统一看待。
- 尽量放弃具体构件类Component作为一个“轻”类，也就是说不要把太多的逻辑和状态放在具体构件类中，能够通过装璜类。
简略实现
package decorator;public class DecoratorPattern { public static void main(String[] args) { Component component = new ConcreteComponent(); component.operation(); System.out.println("---------------------------------"); Component decorator = new ConcreteDecorator(component); decorator.operation(); }}_//形象构件角色_interface Component { public void operation();}_//具体构件角色_class ConcreteComponent implements Component { public ConcreteComponent() { System.out.println("创立具体构件角色"); } public void operation() { System.out.println("调用具体构件角色的办法operation()"); }}_//形象装璜角色_class Decorator implements Component { private Component component; public Decorator(Component component) { this.component=component; } public void operation() { component.operation(); }}_//具体装璜角色_class ConcreteDecorator extends Decorator { public ConcreteDecorator(Component component) { super(component); } public void operation() { super.operation(); addBehavior(); } public void addBehavior() { System.out.println("为具体构件角色减少额定的性能addBehavior()"); }} 4 策略模式(Strategy)
男生追妹子时，个别都会用到这种模式，常见的策略有这些：约会吃饭；看电影；看演唱会；逛街；去旅行……，尽管做的事件不同，但能够互相替换，惟一的指标都是捕捉妹子的芳心。
策略模式构造
- Context: 环境类
- Strategy: 形象策略类
- ConcreteStrategy: 具体策略类
结构图：
时序图：
优缺点
- 长处：策略模式提供了对“开闭准则”的完满反对，用户能够在不批改原有零碎的根底上抉择算法或行为。干掉简单难看的if-else。
- 毛病：调用时，必须提前晓得都有哪些策略模式类，能力自行决定以后场景该应用何种策略。
试用场景
一个零碎须要动静地在几种可替换算法中抉择一种。不心愿使用者关怀算法细节，将具体算法封装进策略类中。
注意事项
肯定要在策略类的正文中阐明该策略的用处和实用场景。
简略实现
package strategy;public class StrategyPattern { public static void main(String[] args) { Context context = new Context(); Strategy strategyA = new ConcreteStrategyA(); context.setStrategy(strategyA); context.algorithm(); System.out.println("-----------------"); Strategy strategyB = new ConcreteStrategyB(); context.setStrategy(strategyB); context.algorithm(); }}_//形象策略类_interface Strategy { public void algorithm(); _//策略办法_}_//具体策略类A_class ConcreteStrategyA implements Strategy { public void algorithm() { System.out.println("具体策略A的策略办法被拜访！"); }}_//具体策略类B_class ConcreteStrategyB implements Strategy { public void algorithm() { System.out.println("具体策略B的策略办法被拜访！"); }}_//环境类_class Context { private Strategy strategy; public Strategy getStrategy() { return strategy; } public void setStrategy(Strategy strategy) { this.strategy=strategy; } public void algorithm() { strategy.algorithm(); }} 5 代理模式(Proxy)
淘宝店客服总是会收到十分多的反复问题，例如：有没有现货？什么时候发货?发什么快递？大量答复重复性的问题太烦了，于是就呈现了小蜜机器人，他来帮客服答复那些已知的问题，当碰到小蜜无奈解答的问题时，才会转到人工客服。这里的小蜜机器人就是客服的代理。
代理模式构造
代理模式蕴含如下角色：
- Subject: 形象主题角色
- Proxy: 代理主题角色
- RealSubject: 实在主题角色
结构图：
时序图：
优缺点
- 长处：代理能够协调调用方与被调用方，升高了零碎的耦合度。依据代理类型和场景的不同，能够起到管制安全性、减小零碎开销等作用。
- 毛病：减少了一层代理解决，减少了零碎的复杂度，同时可能会升高零碎的相应速度。
试用场景
实践上能够代理任何对象，常见的代理模式有：
- 近程(Remote)代理：为一个位于不同的地址空间的对象提供一个本地的代理对象，这个不同的地址空间能够是在同一台主机中，也可是在另一台主机中，近程代理又叫做大使(Ambassador)。
- 虚构(Virtual)代理：如果须要创立一个资源耗费较大的对象，先创立一个耗费绝对较小的对象来示意，实在对象只在须要时才会被真正创立。
- Copy-on-Write代理：它是虚构代理的一种，把复制（克隆）操作提早到只有在客户端真正须要时才执行。一般来说，对象的深克隆是一个开销较大的操作，Copy-on-Write代理能够让这个操作提早，只有对象被用到的时候才被克隆。
- 爱护(Protect or Access)代理：管制对一个对象的拜访，能够给不同的用户提供不同级别的应用权限。
- 缓冲(Cache)代理：为某一个指标操作的后果提供长期的存储空间，以便多个客户端能够共享这些后果。
- 防火墙(Firewall)代理：爱护指标不让歹意用户靠近。
- 同步化(Synchronization)代理：使几个用户可能同时应用一个对象而没有抵触。
- 智能援用(Smart Reference)代理：当一个对象被援用时，提供一些额定的操作，如将此对象被调用的次数记录下来等。
简略实现
package proxy;public class ProxyPattern { public static void main(String[] args) { Proxy proxy = new Proxy(); proxy.request(); }}_//形象主题_interface Subject { void request();}_//实在主题_class RealSubject implements Subject { public void request() { System.out.println("拜访实在主题办法..."); }}_//代理_class Proxy implements Subject { private RealSubject realSubject; public void request() { if (realSubject==null) { realSubject=new RealSubject(); } preRequest(); realSubject.request(); afterRequest(); } public void preRequest() { System.out.println("拜访实在主题之前的预处理。"); } public void afterRequest() { System.out.println("拜访实在主题之后的后续解决。"); }} 6 观察者模式(Observer)
出差在外，想理解孩子在家的状况，这时候只有退出“相亲相爱一家人”群，老爸老妈会常常把孩子的照片和视频发到群里，你要做的就是作为一个观察者，刷一刷群里的信息就可能理解所有了。
观察者模式构造
观察者模式蕴含如下角色：
- Subject：指标
- ConcreteSubject：具体指标
- Observer：观察者
- ConcreteObserver：具体观察者
结构图：
时序图：
优缺点
- 长处：将简单的串行解决逻辑变为单元化的独立解决逻辑，被观察者只是依照本人的逻辑收回音讯，不必关怀谁来生产音讯，每个观察者只解决本人关怀的内容。逻辑互相隔离带来简略清新的代码构造。
- 毛病：观察者较多时，可能会破费肯定的开销来发消息，但这个音讯可能仅一个观察者生产。
实用场景
实用于一对多的的业务场景，一个对象产生变更，会触发N个对象做相应解决的场景。例如：订单调度告诉，工作状态变动等。
注意事项
防止观察者与被观察者之间造成循环依赖，可能会因而导致系统解体。
简略实现
package observer;import java.util.*;public class ObserverPattern{ public static void main(String[] args) { Subject subject = new ConcreteSubject(); Observer obsA = new ConcreteObserverA(); Observer obsb = new ConcreteObserverB(); subject.add(obsA); subject.add(obsB); subject.setState(0); }}_//形象指标_abstract class Subject{ protected List<Observer> observerList = new ArrayList<Observer>(); _//减少观察者办法_ public void add(Observer observer) { observers.add(observer); } _//删除观察者办法_ public void remove(Observer observer) { observers.remove(observer); } public abstract void notify(); _//告诉观察者办法_}_//具体指标_class ConcreteSubject extends Subject{ private Integer state; public void setState(Integer state){ this.state = state; _// 状态扭转告诉观察者_ notify(); } public void notify() { System.out.println("具体指标状态产生扭转..."); System.out.println("--------------"); for(Observer obs:observers) { obs.process(); } } }_//形象观察者_interface Observer{ void process(); _//具体的解决_}_//具体观察者A_class ConcreteObserverA implements Observer{ public void process() { System.out.println("具体观察者A解决！"); }}_//具体观察者B_class ConcreteObserverB implements Observer{ public void process() { System.out.println("具体观察者B解决！"); }}原文链接
本文为阿里云原创内容，未经容许不得转载。