
设计模式
笔记
姜希成
岁月流逝,将来的某时某处,我会在叹息中想起,林间的路分成两股,而我选择了人迹罕至之徒,那一刻起,一切差别已成定铸。
展开
-
行为型-策略模式
注入对象,改变行为。这是一个很有意思的模式,它可以有多种表现形式,只要满足注入对象,改变行为。学习这个模式,必须忘记网上和书上的标准类图。案例 Comparator: Arrays.sort(T[], Comparator)注入不同的Comparator,排序的方式也不同。这是最常见的策略模式的表现形式,没必要画什么图。案例 Spring 后置处理器: applyBeanPostProcessorsBeforeInstantiation与上一个策略模式比较,有点主客颠倒的意思。 protec原创 2020-11-07 23:08:32 · 372 阅读 · 0 评论 -
结构型-过滤器
使用不同的标准来过滤一组对象。在过滤器链里不断地doFilter()案例 spring SecurityFilterChain// SecurityFilterChain 类 private void doFilterInternal(ServletRequest request, ServletResponse response,FilterChain chain) throws IOException, ServletException { // 省略 // 获取 SecurityFil原创 2020-11-07 17:41:11 · 142 阅读 · 0 评论 -
结构型-适配器
使用不完全匹配的功能(目的是合并)。案例 AOP黄色是适配器,把橙色装入紫色,变成蓝色的子类,供绿色使用。就完成了橙色到蓝色的适配。绿色调用蓝色的时候,实际上调用的紫色中的橙色。黄色代码:class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable { @Override public boolean supportsAdvice(Advice advice) { return (advice inst原创 2020-11-07 15:38:29 · 146 阅读 · 0 评论 -
结构型-桥接
把两个对象组合起来,配合工作(目的是分离)。将两个维度的功能组合起来,使其独立变化。比如Spring中的分层,把controller、service和dao层分开,就是桥接。原创 2020-11-07 14:39:05 · 106 阅读 · 0 评论 -
创建型-原型
用于创建重复的对象,同时又能保证性能。就是克隆。比如 spring @Scope(“prototype”),太复杂了,没空研究。原创 2020-11-07 14:23:16 · 136 阅读 · 0 评论 -
创建型-单例
确保一个类只有一个实例,并提供一个全局访问点。这个最经典的就是Spring了,在Spring中创建单例太简单了,这里不介绍Spring。构造函数私有化提供全局访问点懒汉式class Single { public final static Single INSTANCE = new Single(); private Single(){}}饿汉式双重检验锁public class Single { private static volatile Single INSTAC原创 2020-11-07 13:37:11 · 94 阅读 · 0 评论 -
创建型-建造者
把复杂的构建过程封装起来,这种模式用途很广泛,所有以Builder结尾的类几乎都是建造者模式。比如最常用的StringBuilder,从它的使用上可以看出建造者模式的易用性极强。StringBuilder builder = new StringBuilder();builder.append("1").append("2");这个就没有固定的规则了,按照你自己的想法和需求,自己写建造者吧。对于简单的需求,可以使用 Lombok 里的 @Builder 注解。...原创 2020-11-07 13:19:44 · 91 阅读 · 0 评论 -
创建型-抽象工厂
按系列生产案例 数据库驱动生产mysql驱动系列对象,可以方便的扩展其他驱动,只需引入对应的jar包原创 2020-11-07 12:28:47 · 143 阅读 · 0 评论 -
创建型-工厂方法
将工厂类抽象出一个接口,对象的创建方法延迟到工厂子类去实现。案例原创 2020-11-07 11:13:15 · 111 阅读 · 0 评论 -
创建型-简单工厂
并不是一个真正的模式,但是也有他的应用场景,所谓不要拘泥于模式优点:简单易懂应用场景:不变的业务,因此并没有违背对修改关闭,因为不可能修改它比如以下场景,根据性别定制治疗计划,对于受理的物种,既然只有雌性和雄性,那么还有必要写一个对扩展开放的工厂模式吗?这种场景下,简单工厂,简单易懂switch (gender) { case "Female": // 业务逻辑 ..... return TreatmentPlan(...); // 根据业务进行传参 case "Male":原创 2020-11-07 10:28:17 · 162 阅读 · 0 评论 -
设计原则
最重要的原则找出可能变化的部分,独立出来,不要和不需要变化的代码混在一起面向接口编程,不要针对实现编程多用组合,少用继承松耦合对象之间的交互对扩展开放,对修改关闭依赖抽象,不依赖具体类最少知识原则,一个类对于其他类,知道的越少越好别调用我,我会调用你一个类只有一个引起变化的原因警惕为实际需要而使用模式,不要假想简单才是王道,不要拘泥于模式模式是工具,不是规则,需要适当调整以符合你的需求...原创 2020-09-30 12:56:02 · 101 阅读 · 0 评论