4.5. 设计模式¶
4.5.1. 设计模式的六大原则¶
-
开闭原则：对扩展开放,对修改关闭，多使用抽象类和接口。
里氏替换原则：基类可以被子类替换，使用抽象类继承,不使用具体类继承。
依赖倒转原则：要依赖于抽象,不要依赖于具体，针对接口编程,不针对实现编程。
接口隔离原则：使用多个隔离的接口,比使用单个接口好，建立最小的接口。
迪米特法则：一个软件实体应当尽可能少地与其他实体发生相互作用，通过中间类建立联系。
合成复用原则：尽量使用合成/聚合,而不是使用继承。
4.5.2. 23种常见设计模式¶
4.5.3. 应用场景¶
-
结构型模式：
适配器：用来把一个接口转化成另一个接口，如 java.util.Arrays#asList()。
桥接模式：这个模式将抽象和抽象操作的实现进行了解耦，这样使得抽象和实现可以独立地变化，如JDBC；
组合模式：使得客户端看来单个对象和对象的组合是同等的。换句话说，某个类型的方法同时也接受自身类型作为参数，如 Map.putAll，List.addAll、Set.addAll。
装饰者模式：动态的给一个对象附加额外的功能，这也是子类的一种替代方式，如 java.util.Collections#checkedList|Map|Set|SortedSet|SortedMap。
享元模式：使用缓存来加速大量小对象的访问时间，如 valueOf(int)。
代理模式：代理模式是用一个简单的对象来代替一个复杂的或者创建耗时的对象，如 java.lang.reflect.Proxy
创建模式:
抽象工厂模式：抽象工厂模式提供了一个协议来生成一系列的相关或者独立的对象，而不用指定具体对象的类型，如 java.util.Calendar#getInstance()。
建造模式(Builder)：定义了一个新的类来构建另一个类的实例，以简化复杂对象的创建，如：java.lang.StringBuilder#append()。
工厂方法：就是 一个返回具体对象的方法，而不是多个，如 java.lang.Object#toString()、java.lang.Class#newInstance()。
原型模式：使得类的实例能够生成自身的拷贝、如：java.lang.Object#clone()。
单例模式：全局只有一个实例，如 java.lang.Runtime#getRuntime()。
行为模式：
责任链模式：通过把请求从一个对象传递到链条中下一个对象的方式，直到请求被处理完毕，以实现对象间的解耦。如 javax.servlet.Filter#doFilter()。
命令模式：将操作封装到对象内，以便存储，传递和返回，如：java.lang.Runnable。
解释器模式：定义了一个语言的语法，然后解析相应语法的语句，如，java.text.Format，java.text.Normalizer。
迭代器模式：提供一个一致的方法来顺序访问集合中的对象，如 java.util.Iterator。
中介者模式：通过使用一个中间对象来进行消息分发以及减少类之间的直接依赖，java.lang.reflect.Method#invoke()。
空对象模式：如 java.util.Collections#emptyList()。
观察者模式：它使得一个对象可以灵活的将消息发送给感兴趣的对象，如 java.util.EventListener。
模板方法模式：让子类可以重写方法的一部分，而不是整个重写，如 java.util.Collections#sort()。
4.5.4. 单例模式¶
4.5.5. 责任链模式¶
TODO
4.5.6. MVC¶
-
模型(model)－视图(view)－控制器(controller)
4.5.7. IOC¶
-
正向控制：传统通过new的方式。反向控制，通过容器注入对象。
作用：用于模块解耦。
DI：Dependency Injection，即依赖注入，只关心资源使用，不关心资源来源。
4.5.8. AOP¶
-
Spring AOP使用的动态代理，主要有两种方式：JDK动态代理和CGLIB动态代理。
-
Spring AOP 框架对 AOP 代理类的处理原则是：如果目标对象的实现类实现了接口，Spring AOP 将会采用 JDK 动态代理来生成 AOP 代理类；如果目标对象的实现类没有实现接口，Spring AOP 将会采用 CGLIB 来生成 AOP 代理类
4.5.9. UML¶
4.5.10. 微服务思想¶
康威定律¶
-
定律一：组织沟通方式会通过系统设计表达出来，就是说架构的布局和组织结构会有相似。
定律二：时间再多一件事情也不可能做的完美，但总有时间做完一件事情。一口气吃不成胖子，先搞定能搞定的。
定律三：线型系统和线型组织架构间有潜在的异质同态特性。种瓜得瓜，做独立自治的子系统减少沟通成本。
定律四：大的系统组织总是比小系统更倾向于分解。合久必分，分而治之。