UML例子
该例子主要有继承关系，实现接口关系，依赖关系，组合（合成）关系，关联关系。
UML中接口的两种表示方法：
简单工厂模式
如果只有计算父类和具体的加减乘除子类就已经满足封装继承多态了，但是需要增加操作类型时需要修改父类代码，需要实例化父类对象，安全性不高。考虑用一个单独的类做创建实例的过程，称为工厂，实例化工厂对象。
策略模式
案例：商场促销，各种折扣和满减活动。可以用简单工厂解决该问题，但是简单工厂只是解决对象的创建问题，工厂本身包括了所有的收费方式，每次新活动都需要修改工厂类，代码需要重新编译部署，所以不是一种好的处理方式。
什么是策略模式？定义算法家族并封装起来，这些算法之间可以相互替换，算法的使用者不会受到算法变化带来的影响。
此时，对于算法的选择需要在Context类中实现，在客户端传递不同的对象。将简单工厂和策略模式相结合，就可以实现在客户端只实例一个Context类，将算法的选择作为字符串传递，耦合度更低。
策略模式的Strategy类层次为Context定义了一系列的可重用的算法行为，另一个优点是简化了单元测试，因为每个算法都是一个类，可以通过接口单独测试。最重要的是修改一个算法完全不会影响到其他的代码。
单一职责原则
就一个类而言，应该仅有一个引起该类变化的原因。
开放-封闭原则
类、模块、函数等等应该是可以扩展，但不可修改的。能做到面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
依赖倒置原则
抽象不依赖细节，细节应该依赖抽象。针对接口编程。
里氏代换原则
凡是可以使用父类的地方，都应可以使用子类。
装饰模式（Decorator）
有一些场景是需要把所需的功能按正确的顺序串联起来进行控制。
Component定义一个对象接口，可以给这些对象动态地添加职责。ConcreteComponent是定义一个具体的对象，也可以给这个对象添加一些职责。Decorator是装饰抽象类，继承了Component，从外类来扩展Component类的功能，但对于Component来说，无需知道Decorator类的存在。而ConcreteDecorator就是具体的装饰对象，起到给Component添加职责的功能。
装饰模式就是利用ConcreteDecorator类中的方法对对象进行包装，这样每个装饰对象的实现就和如何使用这个对象分离，每个装饰对象只关心自己的功能，不需要关心如何被添加到对象链当中。
至于Component类和ConcreteComponent类，如果只有一个ConcreteComponent类而没有抽象的Component类，那么Decorator就可以是ConcreteComponent的一个子类。同样的道理，如果只有一个ConcreteDecorator类，就没必要设置一个Decorator抽象类，直接把Decorator和ConcreteDecorator的职责合并成一个类。
装饰模式是为已有功能动态添加更多功能的一种方式。当系统需要新功能时，向旧类中添加新的代码，这些新代码通常装饰了原有类的核心职责或主要行为，但增加了主类的复杂程度。而装饰模式把每个要装饰的功能放在单独的类中，并让这个类包装它所要装饰的对象，当需要时，客户代码就可以根据需要地选择这些装饰类。
代理模式
简单理解就是为其他对象提供一种代理以控制对这个对象的访问，第三方不知道是这个对象。
应用场景：
- 远程代理，为一个对象在不同地址空间提供局部代理，隐藏一个对象存在于不同地址空间的事实。
- 虚拟代理，根据需要创建开销很大的对象，通过它存放实例化需要很长时间的真实对象。比如一个很多图片和内容的网页，打开时很快就能刷新出来，因为那些图片框就是使用了虚拟代理的方式保存了图片的路径和大小。
- 安全代理，用来控制真实对象访问时的权限。
- 智能指引，当调用真实对象时，代理处理另外的一些事。
工厂方法模式
将工厂类抽象为接口，具体工厂实现方法。在简单工厂模式中，如果要增加新的计算方法，需要修改客户端代码，增加计算类，最重要的是要修改工厂类中的代码逻辑，增加判断，这就违背了开闭原则，对修改开放了。如果采用工厂方法模式，只要增加新的方法工厂类去实现工厂抽象类，满足对增加开放，对修改关闭。
工厂方法模式定义一个用于创建对象的接口，让子类决定实例化哪一个计算类，工厂方法模式将一个类的实例化延迟到其子类。
原型模式
涉及引用、浅拷贝、深拷贝的知识。
模板方法模式
当我们要完成在某个细节层次一致的一系列过程步骤，但个别步骤在更详细的层次上可能不同时，通常考虑用模板方法模式来处理。定义一个操作中的算法的框架，将一些步骤延迟到子类中。模板方法模式使得子类不改变算法的结构便可重定义该算法的具体步骤。
迪米特法则
也叫最少知识原则，如果两个类不必直接通信，那么这两个类就不应当发生直接的相互作用。如果一个类需要调用另一个类的方法时，可以通过第三者转发调用。主要强调类之间的松耦合。
外观模式
为子系统中的一组接口提供一个一致的界面，该模式定义了一个高层接口，使得子系统更容易使用。
那么何时使用外观模式呢?首先，在设计阶段就应该在不同架构层之间建立接口；其次，在开发阶段增加外观接口可以减少依赖；最后，维护一个旧系统时，可以为新系统开发一个外观类，来提供与旧系统之间的联系，让新系统与接口对象交互，接口对象与旧系统交互。如下图所示。
建造者模式
对于一个有稳定过程的需求，而过程的细节不同，也就是要将一个复杂对象的构建和表示分离，导致同样的构建过程可以创建不同的表示时，可以使用建造者模式，也叫生成器模式。客户端只需要指定建造的类型就可以，不需要知道具体的建造过程和细节。
观察者模式
又叫发布-订阅(Publish/Subscribe)模式，定义了一种一对多的依赖关系，让多个观察者对象同事监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
什么时候使用观察者模式呢？当一个对象的改变需要同时改变其他对象的时候，而且不知道具体有多少对象有待改变时，应该考虑使用该模式。观察者模式其实就是在解耦，让耦合的双方都依赖于抽象，而不是依赖于具体。
抽象工厂模式
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
最大的优点是易于交换产品系列，具体工厂类在一个应用中只在初始化的时候出现一次，使得改变一个应用的具体工厂变得非常容易，不同的具体工厂可以使用不同的产品配置。
缺点在于要是增加功能，需要增加三个类，还有客户端程序不止一个，很多地方在使用AbstractProduct，这需要大量的改动。
状态模式
当一个对象的内在状态改变时允许改变其行为，主要解决的是当控制一个对象状态转换的代码过于复杂时，把状态判断逻辑转移到表示不同状态的一系列类当中。当然，如果状态判断的逻辑很简单，就不必使用设计模式了。
适配器模式（Adapter）
将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以一起工作。
这里有一个适配器模式的简单应用例子。
备忘录模式
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。
比较适用于功能比较复杂的，但需要维护或记录属性历史的类；或者需要保存的属性只是众多属性中的一小部分时。可以把复杂的对象内部信息对其他的对象屏蔽起来，当对象状态改变时，如果状态无效，就可以使用备忘录状态复原。
组合模式
将对象组合成树形结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
反复使用Composite就可以实现树形结构。这里由于接口Component声明了Add和Remove方法，导致Leaf也有，但是Leaf不需要有，这就导致了安全性有一些问题。如果在Component中不声明Add和Remove，而是在Composite类中增加，就没有这个问题，但由于Leaf和Composite具有不同的方法，业务逻辑代码调用时需要进行判断，带来了不便。
什么时候使用组合模式？需求中是体现部分与整体层次的结构时，同时希望用户可以忽略组合对象和单个对象之间的不同，统一使用组合结构中的所有对象时，可以考虑使用组合模式。
迭代器模式
提供一种方法顺序访问聚合对象中的所有元素，且不暴露该对象的内部表示。对聚集进行多种方式的遍历时也可以使用迭代器模式。总之，为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项的统一接口。现在高级语言中的一些特性已经包含了迭代器。
单例模式
将构造函数声明为私有，外部就不能进行实例化了。写一个public方法在类外获取一个该类的对象，对象在类内进行私有创建。就是保证类只有一个实例，并且给程序提供一个访问该实例的访问点。
还可以将类对象声明为静态，进行静态初始化，这种方式被称为饿汉式单例类；与之对应的是在类对象第一次使用时候的初始化，被称为懒汉式单例类。
桥接模式
合成聚合原则：尽量使用合成/聚合，尽量不要使用类继承。原因是父类和子类的依赖关系限制了灵活性。这有助于保持每个类被封装，并被集中到单个任务上，这样继承层次会保持小规模。
所谓桥接模式，就是将抽象部分和实现部分分离，使他们都可以独立变化。
命令模式
将一个请求封装为一个对象，从而可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
职责链模式
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，知道有一个对象处理它为止。
中介者模式
迪米特法则要求两个不必直接通信的类不应当发生直接的相互作用。中介者模式是利用一个中介对象来封装一系列的对象交互，中介者使各对象不必显示地相互引用，从而达到松耦合的目的，而且可以独立地改变它们之间的交互。
该模式的优点是减少了各个具体对象的耦合，使得可以独立地改变和复用各个具体对象和中介对象；同时由于中介封装了对象的交互行为，这样中介者就可以从关注对象行为转为关注对象的交互，站到了更宏观的角度。
应用场景一般是一组对象以定义良好但复杂的方式进行通信的场合，例如想定制一个分布在多个类中的行为，但又不像生成太多子类的场合。
享元模式
利用共享技术有效地支持大量细粒度的对象。
应用场景：如果一个应用程序使用了大量的对象，从而造成了很大的存储开销时应该考虑使用；另外，如果对象的大多数状态是外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑该模式。
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。例如正则表达式。
如果一种类型的问题发生的频率足够高，那么就可能值得将该问题的各个实例表示为一个简单的句子。这样就可以构建一个解释器，通过解释这些句子来解决该问题。
用了解释器模式，就意味着可以很容易改变和扩展文法，因为该模式使用类来表示文法，可以使用继承来改变或扩展文法，
访问者模式
表示一个作用于某对象结构中的元素的操作，它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
该模式适用于数据结构相对稳定的系统，把数据结构和作用于结构上的操作之间的耦合解开了。
标签：总结,对象,可以,接口,工厂,一个,模式,简单,设计模式 From： https://www.cnblogs.com/hql5/p/16901133.html