⼤话设计模式、UML、设计模式Java版完全总结
此篇博客为阅读⼤话设计模式后的笔记记录（ 读完本⽂>≈读完《⼤话设计模式》 ），注意是笔记形式，优先适合于对设计模式有⼀定了解的读者，希望短时间快速温习的读者，同时也对所有设计模式添加了完整代码诠释与注释，⽅便初学者的理解，另外，⽂章末尾有对所有设计模式的总结，读者若对部分设计模式容易混淆，可以到⽂章末尾进⾏了解，其中⽂章有些内容我觉得不⽅便展开的，会附上我认为的⽐较优秀的博客地址进⾏讲解。
（长⽂警告！建议收藏后慢慢品读）
⽬录
Interpreter)
设计模式分为三⼤类（加红代表常⽤）：
创建型模式（五种）：⼯⼚⽅法模式、抽象⼯⼚模式、单例模式、建造者模式、原型模式。
结构型模式（七种）：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
⾏为型模式（⼗⼀种）：策略模式、模板⽅法模式、观察者模式、迭代器模式、责任链/职责链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
UML讲解
或参考：
UML即Unified Model Language，是⼀种建模语⾔，也是标准建模语⾔。
常见的有以下⼏种关系：
关系所表现的强弱程度依次为：组合>聚合>关联>依赖；
聚合跟组合其实都属于关联 只不过它们是两种特殊的关联
泛化/继承（Generalization）
继承（继承⽗类）：带空⼼三⾓形的直线表⽰
实现（Realization）
（实现接⼝）：带空⼼三⾓形的虚线表⽰
依赖(Dependency)
类与类之间最弱的关系，依赖可以简单的理解⼀个类使⽤了另⼀个类：带箭头的虚线表⽰依赖
例如：Person类使⽤了car类⾥⾯的speed属性（⼀般在⽅法参数）
关联（Association)
⼀个类和另⼀类有联系：带箭头的实线表⽰关联
例如：Person类⾥⾯有Address类属性（⼀般在成员变量）
聚合（Aggregation）
关联关系的⼀种，属于较强的关联，表⽰整体与部分的关系，但是部分可以脱离整体⽽存在：带空⼼菱形的直线加箭头表⽰，空⼼菱形指向整体，has-a关系
例如：Person类⾥⾯有car类属性，⼈拥有车，车可以脱离⼈存在
组合(Composition)
关联关系的⼀种，表⽰部分和整体的关系，但是部分存活周期受到整体的影响，若整体不存在则部分也将不存在。此时部分需在整体的构造⽅法中创建：带实⼼菱形的直线加箭头表⽰。实⼼菱形指向整体，Contains-a关系
例如：person类⾥⾯有finger类属性，⼈拥有⼿指，⼿指不能脱离⼈存在
设计模式原则
总原则
开闭原则OCP
对扩展开放，对修改关闭。在程序需要进⾏拓展的时候，不能去修改原有的代码，⽽是要扩展原有代码，实现⼀个热插拔的效果。所以⼀句话概括就是：为了使程序的扩展性好，易于维护和升级。
设计模式的六⼤原则：
1、单⼀职责原则
不要存在多于⼀个导致类变更的原因，也就是说每个类应该实现单⼀的职责，否则就应该把类拆分。
2、⾥⽒替换原则（Liskov Substitution Principle）
任何基类可以出现的地⽅，⼦类⼀定可以出现。
3、依赖倒置原则（Dependence Inversion Principle）
单例模式的几种实现方式⾯向接⼝编程，依赖于抽象⽽不依赖于具体。写代码时⽤到具体类时，不与具体类交互，⽽与具体类的上层接⼝交互。
4、接⼝隔离原则（Interface Segregation Principle）
每个接⼝中不存在⼦类⽤不到却必须实现的⽅法，如果不然，就要将接⼝拆分。使⽤多个隔离的
5、迪⽶特法则（最少知道原则）（Demeter Principle）
⼀个类对⾃⼰依赖的类知道的越少越好。⽆论被依赖的类多么复杂，都应该将逻辑封装在⽅法的内部，通过public⽅法提供给外部。这样当被依赖的类变化时，才能最⼩的影响该类。
6、合成复⽤原则（Composite Reuse Principle）
优先⾸先使⽤合成/聚合的⽅式，⽽不是使⽤继承。
设计模式
策略模式（Strategy）
多个算法可实现类似功能，若将所有⽅法写在⼀个Utils⾥⾯会导致难以维护，代码复杂。所以策略模
式考虑如何让算法和对象分开来，使得算法可以独⽴于使⽤它的客户⽽变化。具体的⽅案是把⼀个类中经常改变或者将来可能改变的部分提取出来，作为⼀个接⼝，然后在类中包含这个对象的实例，这样类的实例在运⾏时就可以随意调⽤实现了这个接⼝的类的⾏为。
策略模式就是⽤来封装算法的，但在实践中，我们发现可以⽤它来封装⼏乎任何类型的规则，只要在分析过程中听到需要在不同时间应⽤不同的业务规则，就可以考虑使⽤策略模式处理这种变化的可能性。
优点
1、可以动态的改变对象的⾏为
缺点
1、客户端必须知道所有的策略类，并⾃⾏决定使⽤哪⼀个策略类
2、策略模式将造成产⽣很多策略类
public static void main(String[] args) { Context context; context = new Context(new ConcreteStrategy
A()); tInterface(); context = new Context(new ConcreteStrategyB()); tInterface(); context = new Context(new ConcreteStrategyC()); tInterface(); }
输出：
策略A的具体算法实现
策略B的具体算法实现
策略C的具体算法实现
简单⼯⼚模式（Simple Factory）+⼯⼚⽅法（FactoryMethod）
⼯⼚模式可以分为三类，它们的区别如下（这⼀部分可以在看完三种⼯⼚模式后再回来看）：
1）简单⼯⼚模式（Simple Factory）：不符合开放-封闭原则（当我们需要增加⼀种计算时，例如开平⽅。这个时候我们需要先定义⼀个类继承Operation类，其中实现平⽅的代码。除此之外我们还要修改OperationFactory类的代码，增加⼀个case。所以显然违反了）2）⼯⼚⽅法（Factory Method）：⽣产单⼀产品
3）抽象⼯⼚模式（Abstract Factory）：⽣产⼀个产品体系
简单⼯⼚模式只有⼀个具体的⼯⼚类
⼯⼚⽅法模式只有⼀个抽象产品类，⽽抽象⼯⼚模式有多个。
⼯⼚⽅法模式的具体⼯⼚类只能创建⼀个具体产品类的实例，⽽抽象⼯⼚模式可以创建多个。（⼯⼚⽅法在增加⼀个具体产品的时候，都要增加对应的⼯⼚。但是抽象⼯⼚模式只有在新增⼀个类型的具体产品时才需要新增⼯⼚）
⼯⼚⽅法让类的实例化推迟到⼦类中进⾏
简单⼯⼚模式：⼀个上帝类，能够⽣产A车，若有⼀种B车需要⽣产，则需要更改上帝类⼯⼚代码
⼯⼚⽅法模式：去掉了简单⼯⼚模式中⼯⼚⽅法的静态属性，使得它可以被⼦类继承。由于简单⼯⼚模式不仅对扩展开放了，也对修改开放了（每添加⼀个类，就得去⽣成实例的⼯⼚⽅法中增加新的分⽀），违背了“开放-封闭原则”。⼯⼚⽅法把简单⼯⼚的内部逻辑判断转移到了客户端代码来进⾏。缺点：每加⼀个产品，需要额外加⼀个产品⼯⼚的类，增加了额外的开销。
⼯⼚模式⽤于处理 如何获取实例对象问题，建造者模式⽤于处理如何建造实例对象 问题。
⼯⼚⽅法的实现并不能减少⼯作量，但是它能够在必须处理新情况时，避免使已经很复杂的代码更加复杂
通常设计应该是从⼯⼚⽅法开始，当设计者发现需要更⼤的灵活性时，设计便会向其他创建型模式演化。当设计者在设计标准之间进⾏权衡的时候，了解多个创建型模式可以给设计者更多的选择余地

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。