设计模式
This is my study note of Design pattern.
简述
设计模式总共有23种,总共可以分为三大类:
- 创建型模式 5种
1
工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式
- 建构型模式 7种
1
适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式
- 行为型模式 11种
1
策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式
创建型模式
工厂方法模式
1
2
3
4
5
6简单工厂模式:
定义一个创建对象的类,将实例化对象的函数封装在这个类内。
工厂方法模式:
由于简单工厂模式中,修改配置需要更改工厂类中的代码,违背了开闭原则,因此提出了工厂方法解决此类问题。工厂方法定义了一个抽象
方法,将对象的实例化交由子类实现,功能的修改只需要增加类的数量就行了。抽象工厂模式
1
2由于工厂方法中,通过增加类的方法实现功能的拓展,导致用户操作复杂性提高,因此提出抽象工厂方法,即定义了一个接口,用于创建相
关或有依赖的对象簇,无需指明具体类。只需要传进参数,就可以实现对象的实例化。工厂模式一般适用于大量产品需要创建,同时需要共同的接口。
单例模式
1
2
3
4
5
6一个类最多只允许一个对象实例,同时提供了一个全局访问的接口。
单例模式可以分为:预加载和懒加载
预加载:
即在访问之前就将对象实例放到内存中,这样会造成内存的浪费,但是预加载是进程安全的方法。
懒加载:
即在访问时才将对象实例放到内存中,这样不会造成内存的浪费,但是是一种不安全的方法。生成器/建造者模式
1
2
3
4
5
6
7封装一个复杂的对象,并允许按步骤构造。
每个组件的建立都十分困难,但利用组件建立对象十分简单,因此可以将复杂的组件建立部分与组件运用部分分离。
四种角色:
1.产品(product):需要构建的对象
2.抽象生成器(Bulider):该接口不仅要定义产品各个组件的建立方法,还要定义返回产品的对象的方法
3.具体生产器(ConcreteBuilder):实现Builder接口定义的各个方法
4.指挥者(Director):负责向用户提供具体生成器,即按照步骤组装部件,并返回Product原型模式
1
2
3
4
5
6通过复制现有实例来创建新的实例,无需知道相应类的信息。
浅复制:
将一个对象复制后,基本数据类型的变量都会重新创建,而引用类型,指向的还是原对象所指向的。
深复制:
将一个对象复制后,不论是基本数据类型还有引用类型,都是重新创建的。简单来说,就是深复制进行了完全彻底的复制,而浅复制
不彻底。clone明显是深复制,clone出来的对象是是不能去影响原型对象的
结构模式
- 适配器模式
1
2
3
4
5
6
7
8将某个类的接口转换成客户端期待的另一个接口表示,消除接口不匹配所造成的类兼容性问题。
分为:类的适配器模式、对象的适配器模式、接口的适配器模式。
1.类适配器模式
通过多重继承目标接口和被适配者类方式来实现适配
2.对象的适配器模式
对象适配器使用组合实现适配
3.接口适配器模式
当不需要全部实现接口提供的方法时,可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法),那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求,它适用于一个接口不想使用其所有的方法的情况。 - 装饰者模式
1
动态的将新功能附加到对象上,比继承更有弹性。
- 代理模式
1
2
3代理模式给某一个对象提供一个代理对象,并由代理对象控制对原对象的引用,类似中介。
代理模式经常用于客户类不能或者不想直接引用一个委托对象,而代理对象可以在客户端和委托对象中起到中介作用。
分类:1.静态代理 2.动态代理 3.CGLIB代理 - 外观模式
1
2
3
4
5
6
7
8隐藏了系统的复杂性,并向客户端提供了一个可以访问系统的接口。
由三个角色组成:
1.门面角色
外观模式的核心。(自身可以被客户端调用,同时可以调用子系统功能)
2.子系统角色
具体功能的实现
3.客户角色
用于调用门面角色 - 桥接模式
1
将抽象部分与实现部分分离,可以单独的变化。
- 组合模式
1
有时又叫做部分整体模式,它是一种将对象组合成树状的层次结构的模式,用来表示“部分-整体”的关系,使用户对单个对象和组合对象具有一致的访问性。
六大原则
开闭原则
1
即开放封闭原则。软件实体,如类、模块、函数等应该对拓展开放,对修改封闭。
对拓展开放:有新的需求或变化时,对现有代码进行拓展,以适应新的情况。
对修改封闭:类一旦设计完成都可以独立完成其工作,不需要对现有代码进行任何修改。
单一职责原则
1
一个方法只负责一件事情。
里氏替换原则
1
使用的基类可以在任何地方使用继承的子类,完美的替换基类。
依赖倒置原则
1
高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象,抽象不应该依赖于具体实现,具体实现应该依赖于抽象。
接口隔离原则
1
类和类之间应该建立在最小接口的上。即不应该依赖他不需要的接口。
迪米特法则
1
一个对象应当对其他对象有尽可能少地了解,简称类间解耦。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 风声向寂!
评论
ValineDisqus