文章目錄
- 簡介
- 一. Spring用到的設計模式類別
- 1. 創建型模式
- 2. 結構性模式
- 3. 行為型模式
- 二. 設計模式詳解
- 1. 工廠模式
- 1.1 簡單工廠模式
- 1.2 工廠方法模式
- 1.3 抽象工廠模式
- 2. 單例模式
- 2.1 餓漢模式
- 2.2 懶漢模式
- 2.3 破壞單例的方式
- 2.4 注冊式單例模式
- 2.4.1 列舉單例模式
- 2.4.2 容器式單例模式
- 3. 原型模式詳解
- 3.1 淺克隆
- 3.2 深克隆
- 4. 代理模式
- 4.1 為什么要用代理模式?
- 4.2 靜態代理
- 4.3 動態代理
- 4.4 CGLIB代理
- 4.5 JDK動態代理與CGLIB對比
- 4.6 代理模式在Spring中的應用
- 4.7 代理模式的優缺點
- 5. 委派模式
- 6. 策略模式
- 7. 模板模式
- 8. 配接器模式詳解
- 9. 裝飾器模式
- 10.觀察者模式
- 三.GoF23種設計模式簡介
簡介
此文基于之前看【Spring核心原理】整理的學習筆記,建議手擼一遍代碼加深印象,
一. Spring用到的設計模式類別
| 設計模式名稱 | 舉例 | 描述 |
|---|---|---|
| 單例模式 | ApplocationContext | 一個Bean只有一個實體 |
| 原型模式 | scope=“prototype” | 指定創建物件的種類,并且通過復制這些原型創建新的物件 |
| 工廠模式 | BeanFactory | 只對結果負責,封裝創建程序 |
| 裝飾者模式 | BeanWrapper | 包裝,同源 |
| 代理模式 | ProxyFactoryBean, JdkDynamicAopProxy,CglibAopProxy | 找人辦事,增強職責 |
| 委派模式 | DispatcherServlet | 專案找外包公司做 |
| 策略模式 | HandlerMapping | 用戶選擇,結果統一 |
| 配接器模式 | HandlerAdapter | 兼容轉換頭 |
| 模板模式 | JdbcTemplate | 流程標準化,自己實作定制 |
| 觀察者模式 | ContextLoaderListener | 在任務完成時通知 |
1. 創建型模式
- 工廠模式(Factory Pattern)
- 單例模式 (Singleton Pattern)
- 原型模式 (Prototype Pattern)
2. 結構性模式
- 配接器模式 (Adapter Pattern)
- 裝飾者模式 (Decorator Pattern)
- 代理模式 (Proxy Pattern)
3. 行為型模式
- 策略模式 (Strategy Pattern)
- 模板模式 (Template Pattern)
- 委托模式 (Delegate Pattern)
- 觀察者模式 (Observer Pattern)
二. 設計模式詳解
1. 工廠模式
1.1 簡單工廠模式
簡單工廠模式(Simple Factory Pattern)是指由一個工廠物件決定創建哪一種產品類的實體,但它不屬于GoF的23種設計模式.
通過反射的方式生成物件
缺點: 工廠類的職責相對過重,不易于擴展過于復雜的邏輯代碼
public interface Course {
void record();
}
public class JavaCourse implements Course {
@Override
public void record() {
System.out.println("java課程");
}
}
public class CourseFactory {
public static Course getCourse(Class<? extends Course> clas) {
try {
if (null != clas) {
return clas.newInstance();
}
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
public static void main(String[] args) {
Course course=CourseFactory.getCourse(JavaCourse.class);
course.record();
}
}
1.2 工廠方法模式
工廠方法模式(Fatory Method Pattern)是指定義一個創建物件的介面,但讓實作這個介面的類來決定實體化哪個類,工廠方法模式讓類的實體化推遲到子類進行,在工廠方法模式中用戶只需要關心所需產品對應的工廠,無需關心創建細節,而加入新的產品也符合開閉原則
public interface Course {
void record();
}
public class JavaCourse implements Course {
@Override
public void record() {
System.out.println("java課程");
}
}
public interface CourseFactory {
Course getCourse();
}
public class JavaCourseFacotry implements CourseFactory {
@Override
public Course getCourse() {
return new JavaCourse();
}
public static void main(String[] args) {
Course course = new JavaCourseFacotry().getCourse();
course.record();
}
}
1.3 抽象工廠模式
抽象工廠模式(Abstract Factory Pattern)是指提供一個創建一系列相關或者相關依賴物件的介面,無需指定他們的具體實作類.
spring中應用得最廣泛的一種設計模式
public interface Note {
void edit();
}
public interface Video {
void record();
}
public class JavaNote implements Note {
@Override
public void edit() {
System.out.println("撰寫Java筆記");
}
}
public class JavaVideo implements Video {
@Override
public void record() {
System.out.println("錄制Java視頻");
}
}
public interface CourseFactory {
Note getNote();
Video getVideo();
}
public class JavaCourseFactory implements CourseFactory {
@Override
public Note getNote() {
return new JavaNote();
}
@Override
public Video getVideo() {
return new JavaVideo();
}
public static void main(String[] args) {
CourseFactory courseFactory = new JavaCourseFactory();
courseFactory.getNote().edit();
courseFactory.getVideo().record();
}
}
2. 單例模式
單例模式(Singleton Pattern)是指確保一個類在任何情況下都絕對只有一個實體,并提供一個全域訪問點,單例模式是創建型模式,Spring框架中ApplicationContext,資料庫的連接池等也是單例形式
2.1 餓漢模式
餓漢單例模式在類加載的時候就立即初始化,并且創建物件了,它絕對執行緒安全,在執行緒還沒出現之前就實體化了,不存在訪問安全問題
缺點: 類加載時候就初始化,不管用與不用都占用空間,浪費記憶體
public class HungrySingleton {
private static final HungrySingleton INSTANCE = new HungrySingleton();
private HungrySingleton() { }
public static HungrySingleton getInstance() {
return INSTANCE;
}
}
2.2 懶漢模式
懶漢模式的特點是: 被外部類呼叫的時候內部類才會初始化
下面采用內部類方式實作
public class LazySingleton {
private LazySingleton() { }
public static LazySingleton getInstance() {
return LazyHolder.INSTANCE;
}
private static class LazyHolder {
private static final LazySingleton INSTANCE = new LazySingleton();
}
}
2.3 破壞單例的方式
2.3.1反射破壞
public class Main {
public static void main(String[] args) throws Exception {
LazySingleton s1 = LazySingleton.getInstance();
//無聊的情況下,進行破壞
Constructor<LazySingleton> constructor = LazySingleton.class.getDeclaredConstructor();
//強制訪問
constructor.setAccessible(true);
//暴力初始化
Object s2 = constructor.newInstance();
System.out.println(s1 == s2);
}
}
改善LazySingleton防止反射破壞
public class LazySingleton {
private LazySingleton() {
if(LazyHolder.INSTANCE!=null){
throw new RuntimeException("不允許創建多個實體");
}
}
public static LazySingleton getInstance() {
return LazyHolder.INSTANCE;
}
private static class LazyHolder {
private static final LazySingleton INSTANCE = new LazySingleton();
}
}
2.3.2序列化破壞單例
public class SeriableSingleton implements Serializable {
private static final SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton() { }
public static SeriableSingleton getInstance() {
return INSTANCE;
}
}
public static void main(String[] args) {
SeriableSingleton s1 = null;
SeriableSingleton s2 = SeriableSingleton.getInstance();
FileOutputStream fos = null;
try {
fos = new FileOutputStream("SeriableSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("SeriableSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (SeriableSingleton) ois.readObject();
ois.close();
System.out.println(s1);
System.out.println(s2);
System.out.println(s1==s2);
} catch (Exception e) {
e.printStackTrace();
}
}
}

添加readResolve()方法即修復此問題
public class SeriableSingleton implements Serializable {
private static final SeriableSingleton INSTANCE = new SeriableSingleton();
private SeriableSingleton() { }
public static SeriableSingleton getInstance() {
return INSTANCE;
}
private Object readResolve() {
return INSTANCE;
}
}

ObjectInputStream
物件的序列化程序通過ObjectOutputStream和ObjectInputputStream來實作的,那么帶著剛剛的問題,分析一下ObjectInputputStream 的readObject 方法執行情況到底是怎樣的,
private Object readOrdinaryObject(boolean unshared)
throws IOException
{
//此處省略部分代碼
Object obj;
try {
//這里創建的這個obj物件,就是本方法要回傳的物件,也可以暫時理解為是ObjectInputStream的readObject回傳的物件,
obj = desc.isInstantiable() ? desc.newInstance() : null;
} catch (Exception ex) {
throw (IOException) new InvalidClassException(
desc.forClass().getName(),
"unable to create instance").initCause(ex);
}
//此處省略部分代碼
if (obj != null &&
handles.lookupException(passHandle) == null &&
desc.hasReadResolveMethod())
{
Object rep = desc.invokeReadResolve(obj);
if (unshared && rep.getClass().isArray()) {
rep = cloneArray(rep);
}
if (rep != obj) {
handles.setObject(passHandle, obj = rep);
}
}
return obj;
}
-
isInstantiable:如果一個serializable/externalizable的類可以在運行時被實體化,那么該方法就回傳true,
-
desc.newInstance:該方法通過反射的方式呼叫無參構造方法新建一個物件,
-
hasReadResolveMethod:如果實作了serializable 或者 externalizable介面的類中包含readResolve則回傳true
-
invokeReadResolve:通過反射的方式呼叫要被反序列化的類的readResolve方法,
所以,原理也就清楚了,主要在Singleton中定義readResolve方法,并在該方法中指定要回傳的物件的生成策略,就可以防止單例被破壞,
為什么序列化可以破壞單例了?
答:序列化會通過反射呼叫無引數的構造方法創建一個新的物件,
2.4 注冊式單例模式
注冊式單例模式又稱登記式單例模式,都是將每一個實體登記到某個地方,使用唯一的標識來獲取實體.注冊式單例模式有兩種:一種為列舉式單例模式,另一種為容器式單例模式
2.4.1 列舉單例模式
public enum EnumSingleton {
INSTANCE;
private User user;
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
public static EnumSingleton getInstance() {
return INSTANCE;
}
public static class User {
}
public static void main(String[] args) {
EnumSingleton s1 = EnumSingleton.getInstance();
EnumSingleton s2 = EnumSingleton.getInstance();
//true
System.out.println(s1 == s2);
}
}
測驗反射破壞列舉單例模式
EnumSingleton s1 = EnumSingleton.getInstance();
//無聊的情況下,進行破壞
Constructor<EnumSingleton> constructor = EnumSingleton.class.getDeclaredConstructor();
//強制訪問
constructor.setAccessible(true);
//暴力初始化
Object s2 = constructor.newInstance();
System.out.println(s1 == s2);
下面例外顯示沒有找到構造方法,列舉類只有protected型別的構造方法

測驗序列化破壞列舉單例模式
EnumSingleton s1 = null;
EnumSingleton s2 = EnumSingleton.getInstance();
FileOutputStream fos = null;
try {
fos = new FileOutputStream("EnumSingleton.obj");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(s2);
oos.flush();
oos.close();
FileInputStream fis = new FileInputStream("EnumSingleton.obj");
ObjectInputStream ois = new ObjectInputStream(fis);
s1 = (EnumSingleton) ois.readObject();
ois.close();
//輸出true
System.out.println(s1==s2);
} catch (Exception e) {
e.printStackTrace();
}
查看ObjectInputStream的readObject0方法

readEnum方法實作如下
private Enum<?> readEnum(boolean unshared) throws IOException {
if (bin.readByte() != TC_ENUM) {
throw new InternalError();
}
ObjectStreamClass desc = readClassDesc(false);
if (!desc.isEnum()) {
throw new InvalidClassException("non-enum class: " + desc);
}
int enumHandle = handles.assign(unshared ? unsharedMarker : null);
ClassNotFoundException resolveEx = desc.getResolveException();
if (resolveEx != null) {
handles.markException(enumHandle, resolveEx);
}
String name = readString(false);
Enum<?> result = null;
Class<?> cl = desc.forClass();
if (cl != null) {
try {
@SuppressWarnings("unchecked")
Enum<?> en = Enum.valueOf((Class)cl, name);
result = en;
} catch (IllegalArgumentException ex) {
throw (IOException) new InvalidObjectException(
"enum constant " + name + " does not exist in " +
cl).initCause(ex);
}
if (!unshared) {
handles.setObject(enumHandle, result);
}
}
handles.finish(enumHandle);
passHandle = enumHandle;
return result;
}
列舉型別其實通過類名和類物件類找到一個唯一的列舉物件,因此,列舉物件不可能被加載器加載多次
2.4.2 容器式單例模式
spring中的AbstractAutowireCapableBeanFactory
public class ContainerSingleton {
private ContainerSingleton() {
}
private static Map<String, Object> ioc = new ConcurrentHashMap<>();
public static Object getBean(String classsName) {
synchronized (ioc) {
if (!ioc.containsKey(classsName)) {
Object obj = null;
try {
obj = Class.forName(classsName).newInstance();
ioc.put(classsName, obj);
} catch (Exception e) {
e.printStackTrace();
}
return obj;
} else {
return ioc.get(classsName);
}
}
}
public static void main(String[] args) {
for(int i=0;i<10;i++){
new Thread(()->{
System.out.println(getBean(User.class.getName()));
}).start();
}
}
}
3. 原型模式詳解
原型模式(Prototype Pattern)是指原型實體指定創建物件的種類,并且通過復制這些原始創建新的物件.
在Spring中,原型模式應用得非常廣泛,例如scope=“prototype”.
3.1 淺克隆
淺克隆只復制了屬性的值,但是沒有賦值參考物件
public interface Prototype {
Prototype clone();
}
public class BeanUtil {
private BeanUtil(){}
public static Prototype clone(Prototype prototype) {
return prototype.clone();
}
}
public class User implements Prototype {
private String username;
private List<String> hobbyList;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public List<String> getHobbyList() {
return hobbyList;
}
public void setHobbyList(List<String> hobbyList) {
this.hobbyList = hobbyList;
}
@Override
public Prototype clone() {
User user = new User();
user.username = this.username;
user.hobbyList = this.hobbyList;
return user;
}
}
public static void main(String[] args) {
User user = new User();
user.setUsername("test");
user.setHobbyList(Arrays.asList("擼鐵"));
User user1 = (User) BeanUtil.clone(user);
user1.getHobbyList().set(0,"寫博客");
//輸出 寫博客,true
System.out.println(user.getHobbyList().get(0));
}
由于List是參考型別,所以user和user1的hobbyList是一個物件

3.2 深克隆
深克隆在克隆屬性的同時,通過序列化反射生成了一個新的參考地址
public class User implements Cloneable, Serializable {
private String username;
private List<String> hobbyList;
public String getUsername() {
return username;
}
public void setUsername(String username) {
this.username = username;
}
public List<String> getHobbyList() {
return hobbyList;
}
public void setHobbyList(List<String> hobbyList) {
this.hobbyList = hobbyList;
}
@Override
public Object clone() throws CloneNotSupportedException{
//Cloneable.clone介面默認是淺克隆
//return super.clone();
return this.deepClone();
}
public Object deepClone() {
try {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(this);
ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream ois = new ObjectInputStream(bis);
User copy = (User) ois.readObject();
return copy;
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
public static void main(String[] args) {
User user = new User();
user.setUsername("test");
user.setHobbyList(Arrays.asList("擼鐵"));
User user1 =(User) user.clone();
user1.getHobbyList().set(0, "寫博客");
//輸出 擼鐵 false
System.out.println(user.getHobbyList().get(0));
System.out.println(user.getHobbyList() == user1.getHobbyList());
}
4. 代理模式
代理模式(Proxy Pattern)給某一個物件提供一個代理物件,并由代理物件控制對原物件的參考,通俗的來講代理模式就是我們生活中常見的中介,
4.1 為什么要用代理模式?
- 中介隔離作用:在某些情況下,一個客戶類不想或者不能直接參考一個委托物件,而代理類物件可以在客戶類和委托物件之間起到中介的作用,其特征是代理類和委托類實作相同的介面,
- 開閉原則,增加功能:代理類除了是客戶類和委托類的中介之外,我們還可以通過給代理類增加額外的功能來擴展委托類的功能,這樣做我們只需要修改代理類而不需要再修改委托類,符合代碼設計的開閉原則,代理類主要負責為委托類預處理訊息、過濾訊息、把訊息轉發給委托類,以及事后對回傳結果的處理等,代理類本身并不真正實作服務,而是同過呼叫委托類的相關方法,來提供特定的服務,真正的業務功能還是由委托類來實作,但是可以在業務功能執行的前后加入一些公共的服務,例如我們想給專案加入快取、日志這些功能,我們就可以使用代理類來完成,而沒必要打開已經封裝好的委托類,
4.2 靜態代理
- 優點:可以做到在符合開閉原則的情況下對目標物件進行功能擴展,
- 缺點:我們得為每一個服務都得創建代理類,作業量太大,不易管理,同時介面一旦發生改變,代理類也得相應修改,
public interface BuyHouse {
void buyHosue();
}
public class BuyHouseImpl implements BuyHouse{
@Override
public void buyHosue() {
System.out.println("我要買房");
}
}
public class BuyHouseProxy implements BuyHouse {
private BuyHouse buyHouse;
public BuyHouseProxy(final BuyHouse buyHouse) {
this.buyHouse = buyHouse;
}
@Override
public void buyHosue() {
System.out.println("買房前準備錢");
buyHouse.buyHosue();
System.out.println("和中介簽訂合同");
}
}
public class Main {
public static void main(String[] args) {
BuyHouse buyHouse = new BuyHouseImpl();
buyHouse.buyHosue();
BuyHouseProxy buyHouseProxy = new BuyHouseProxy(buyHouse);
buyHouseProxy.buyHosue();
}
}
4.3 動態代理
public class DynamicProxyHandler implements InvocationHandler {
private Object object;
public DynamicProxyHandler(final Object object) {
this.object = object;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("買房前準備");
Object result = method.invoke(object, args);
System.out.println("和中介簽訂合同");
return result;
}
}
public class Main {
public static void main(String[] args) {
BuyHouse buyHouse = new BuyHouseImpl();
BuyHouse proxyBuyHouse = (BuyHouse) Proxy.newProxyInstance(BuyHouse.class.getClassLoader(), new
Class[]{BuyHouse.class}, new DynamicProxyHandler(buyHouse));
proxyBuyHouse.buyHosue();
}
}
注意Proxy.newProxyInstance()方法接受三個引數:
- ClassLoader loader:指定當前目標物件使用的類加載器,獲取加載器的方法是固定的
- Class<?>[] interfaces:指定目標物件實作的介面的型別,使用泛型方式確認型別
- InvocationHandler:指定動態處理器,執行目標物件的方法時,會觸發事件處理器的方法
動態代理總結:雖然相對于靜態代理,動態代理大大減少了我們的開發任務,同時減少了對業務介面的依賴,降低了耦合度,但是還是有一點點小小的遺憾之處,那就是它始終無法擺脫僅支持interface代理的桎梏,因為它的設計注定了這個遺憾,回想一下那些動態生成的代理類的繼承關系圖,它們已經注定有一個共同的父類叫Proxy,Java的繼承機制注定了這些動態代理類們無法實作對class的動態代理,原因是多繼承在Java中本質上就行不通,有很多條理由,人們可以否定對 class代理的必要性,但是同樣有一些理由,相信支持class動態代理會更美好,介面和類的劃分,本就不是很明顯,只是到了Java中才變得如此的細化,如果只從方法的宣告及是否被定義來考量,有一種兩者的混合體,它的名字叫抽象類,實作對抽象類的動態代理,相信也有其內在的價值,此外,還有一些歷史遺留的類,它們將因為沒有實作任何介面而從此與動態代理永世無緣,如此種種,不得不說是一個小小的遺憾,但是,不完美并不等于不偉大,偉大是一種本質,
4.4 CGLIB代理
JDK實作動態代理需要實作類通過介面定義業務方法,對于沒有介面的類,如何實作動態代理呢,這就需要CGLib了,CGLib采用了非常底層的位元組碼技術,其原理是通過位元組碼技術為一個類創建子類,并在子類中采用方法攔截的技術攔截所有父類方法的呼叫,順勢織入橫切邏輯,但因為采用的是繼承,所以不能對final修飾的類進行代理,JDK動態代理與CGLib動態代理均是實作Spring AOP的基礎,
public class BuyHouseTwo {
public void buyHosue() {
System.out.println("我要買房");
}
}
public class CglibProxy implements MethodInterceptor {
public Object getProxy(Class clas) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(clas);
enhancer.setCallback(this);
return enhancer.create();
}
/**
* @param obj 表示要進行增強的物件
* @param method 表示攔截的方法
* @param args 陣串列示引數串列,基本資料型別需要傳入其包裝型別,如int-->Integer、long-Long、double-->Double
* @param methodProxy 表示對方法的代理,invokeSuper方法表示對被代理物件方法的呼叫
* @return 執行結果
*/
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
System.out.println("買房前準備");
Object result = methodProxy.invokeSuper(obj, args);
System.out.println("買房后裝修");
return result;
}
}
public class Main {
public static void main(String[] args) {
CglibProxy cglibProxy = new CglibProxy();
BuyHouseTwo proxy = (BuyHouseTwo) cglibProxy.getProxy(BuyHouseTwo.class);
proxy .buyHosue();
}
}

CGLIB代理總結: CGLIB創建的動態代理物件比JDK創建的動態代理物件的性能更高,但是CGLIB創建代理物件時所花費的時間卻比JDK多得多,所以對于單例的物件,因為無需頻繁創建物件,用CGLIB合適,反之使用JDK方式要更為合適一些,同時由于CGLib由于是采用動態創建子類的方法,對于final修飾的方法無法進行代理,
4.5 JDK動態代理與CGLIB對比
- JDK動態代理:基于Java反射機制實作,必須要實作了介面的業務類才生成代理物件,
- CGLIB動態代理:基于ASM機制實作,通過生成業務類的子類作為代理類,
JDK Proxy的優勢:
最小化依賴關系、代碼實作簡單、簡化開發和維護、JDK原生支持,比CGLIB更加可靠,隨JDK版本平滑升級,而位元組碼類別庫通常需要進行更新以保證在新版Java上能夠使用,
CGLIB的優勢:
無需實作介面,達到代理類無侵入,只操作關心的類,而不必為其他相關類增加作業量,高性能,
4.6 代理模式在Spring中的應用
ProxyFactoryBean核心方法getObject()
public Object getObject() throws BeansException {
this.initializeAdvisorChain();
if (this.isSingleton()) {
return this.getSingletonInstance();
} else {
if (this.targetName == null) {
this.logger.warn("Using non-singleton proxies with singleton targets is often undesirable. Enable prototype proxies by setting the 'targetName' property.");
}
return this.newPrototypeInstance();
}
}
在spring的配置中如果不做任何處理設定,那么spring代理的類都是單例物件,如果修改scope為prototype,則每次創建一個新的物件
spring bean的scope屬性
- singleton 表示在spring容器中的單例,通過spring容器獲得該bean時總是回傳唯一的實體(默認)
- prototype表示每次獲得bean都會生成一個新的物件
Spring利用動態代理實作AOP時有兩個非常重要的類,JdkDynamicAopProxy類和CglibAopProxy類

Spring中的代理選擇原則
- 當Bean有實作介面時,Spring就會用JDK動態代理
- 當Bean沒有實作介面時,Spring會選擇CGLib代理
- spring可以通過配置強制使用CGLib代理
4.7 代理模式的優缺點
優點
- 1.代理模式能將代理物件與真實被呼叫目標物件分離
- 2.在一定程式上降低了系統的耦合性,擴展性好
- 3.可以起到保護目標物件的功能
- 4.可以增強目錄物件的功能
缺點
- 1.代理模式會造成系統設計中類的數量增加
- 2.在客戶端和目標物件中增加一個代理物件,會導致請求速度會變慢
- 3.增加了系統的復雜度
5. 委派模式
委派模式(Delegate Pattern)不屬于GoF 23種設計模式.在委托模式中,有兩個物件參與處理同一個請求,接受請求的物件將請求委托給另一個物件來處理,委托模式是一項基本技巧,許多其他的模式,如狀態模式、策略模式、訪問者模式本質上是在更特殊的場合采用了委托模式,委托模式使得我們可以用聚合來替代繼承,它還使我們可以模擬mixin,
委派模式和代理模式很像,可以看作是一種特殊情況下的靜態全域代理,但是代理模式注重程序,委托模式注重結果, web開發中常用的DispatcherServlet就用到了委托模式.在Spring原始碼中,以Delegate結尾的地方都實作了委派模式
本文以找黃牛買票為例
/**
* @description 票類介面
**/
public interface Ticket {
void doing();
}
public class TrainTicket implements Ticket {
@Override
public void doing() {
System.out.println("買到南昌的飛機票");
}
}
public class ConcertTicket implements Ticket {
@Override
public void doing() {
System.out.println("買許嵩的演唱會票"); //黃牛
}
}
public class Cattle {
public void doing(Ticket ticket) {
System.out.println("我是黃牛");
ticket.doing();
System.out.println("買票結束");
}
}
public class Main {
public static void main(String[] args) {
Cattle cattle=new Cattle();
cattle.doing(new ConcertTicket());
cattle.doing(new TrainTicket());
}
}
6. 策略模式
策略模式(Strategy Pattern)是指定義了演算法家族并分別封裝起來,讓它們可以相互替換,此模式使演算法的變化不會影響使用演算法的用戶.
下面以網購買完東西,結賬時候選擇支付方式為例
public abstract class Payment {
//支付型別
public abstract String getName();
//查詢余額
protected abstract double queryBalance(String uid);
//扣款支付
public PayState pay(String uid,double amount){
if(queryBalance(uid)<amount){
return new PayState(500,"支付失敗","余額不足");
}
return new PayState(200,"支付成功","交易金額:"+amount);
}
}
public class PayState {
private int code;
private Object data;
private String msg;
public PayState(int code,String msg,Object data){
this.code=code;
this.msg=msg;
this.data=data;
}
@Override
public String toString(){
return "支付狀態:["+code+"],"+msg+",交易詳情:"+data;
}
}
public class AliPay extends Payment {
@Override
public String getName() {
return "支付寶";
}
@Override
protected double queryBalance(String uid) {
return 900;
}
@Override
public PayState pay(String uid, double amount) {
return super.pay(uid, amount);
}
}
public class WechatPay extends Payment {
@Override
public String getName() {
return "微信支付";
}
@Override
protected double queryBalance(String uid) {
return 257;
}
@Override
public PayState pay(String uid, double amount) {
return super.pay(uid, amount);
}
}
public class PayStrategy {
public static final String ALI_PAY = "AliPay";
public static final String WECHAT_PAY = "WechatPay";
public static final String DEFAULT_PAY = ALI_PAY;
private static Map<String, Payment> payStrategy = new HashMap<String, Payment>();
static {
payStrategy.put(ALI_PAY, new AliPay());
payStrategy.put(WECHAT_PAY, new WechatPay());
}
/**
* 根據key選擇對應的策略
*/
public static Payment get(String payKey) {
if (!payStrategy.containsKey(payKey)) {
return payStrategy.get(DEFAULT_PAY);
}
return payStrategy.get(payKey);
}
}
public class Order {
private String uid;
private String orderId;
private double amount;
public Order(String uid, String orderId, double amount) {
this.uid = uid;
this.orderId = orderId;
this.amount = amount;
}
public PayState pay(String payKey) {
Payment payment = PayStrategy.get(payKey);
System.out.println("歡迎使用" + payment.getName());
System.out.println("本次校次金額為:" + amount + ",開始扣款.....");
return payment.pay(uid, amount);
}
}
public class Main {
public static void main(String[] args) {
Order order=new Order("1","20210118",389);
//選擇策略支付
System.out.println(order.pay(PayStrategy.ALI_PAY));
}
}
策略模式原始碼中應用場景
1.策略模式在JDK中原始碼的體驗
比較容器-Comparator介面,大家常用的compare()方法就是一個策略模式的抽象實作
@FunctionalInterface
public interface Comparator<T> {
int compare(T o1, T o2);
}
2.在Spring中的應用
Spring在初始化也采用了策略模式,即不同型別的類采用不同的初始化策略,
InstantiationStrategy介面
public interface InstantiationStrategy {
Object instantiate(RootBeanDefinition var1, @Nullable String var2, BeanFactory var3) throws BeansException;
Object instantiate(RootBeanDefinition var1, @Nullable String var2, BeanFactory var3, Constructor<?> var4, Object... var5) throws BeansException;
Object instantiate(RootBeanDefinition var1, @Nullable String var2, BeanFactory var3, @Nullable Object var4, Method var5, Object... var6) throws BeansException;
}
頂層的策略抽象非常簡單,它下面有兩種策略: SimpleInstantiationStrategy
CglibSubclassingInstantiationStrategy,
public class CglibSubclassingInstantiationStrategy extends SimpleInstantiationStrategy {
}
CglibSubclassingInstantiationStrategy繼承自SimpleInstantiationStrategy類,說明實際應用中多種策略可以繼承使用.
策略模式的優缺點:
優點:策略符合開閉原則,策略模式可避免使用多重條件陳述句,如if…else陳述句,switch陳述句,使用策略模式可以提供演算法的保密性和安全性
缺點:客戶端必須知道所有策略,并且自行決定使用哪個策略
7. 模板模式
模板模式又叫模板方法模式(Template Method Pattern),是指定義一個演算法的骨架,并允許子類為一個或者多個步驟提供實作.模板模式使得子類可以在不變演算法的前提下,重新定義演算法的某些步驟,屬于行為型設計模式,模板模式使用與以下場景
- 1.一次性實作一個演算法的不變部分,并將可變的行為交給子類實作
- 2.各子類中公共行為被提取出來并集中到一個公共的父類中,從而避免代碼重復
我們將創建一個定義操作的 Game 抽象類,其中,模板方法設定為 final,這樣它就不會被重寫,Cricket 和 Football 是擴展了 Game 的物體類,它們重寫了抽象類的方法,
TemplatePatternDemo,我們的演示類使用 Game 來演示模板模式的用法,

public abstract class Game {
abstract void initialize();
abstract void startPlay();
abstract void endPlay();
//模板
public final void play(){
//初始化游戲
initialize();
//開始游戲
startPlay();
//結束游戲
endPlay();
}
}
public class Cricket extends Game {
@Override
void endPlay() {
System.out.println("Cricket Game Finished!");
}
@Override
void initialize() {
System.out.println("Cricket Game Initialized! Start playing.");
}
@Override
void startPlay() {
System.out.println("Cricket Game Started. Enjoy the game!");
}
}
public class Football extends Game {
@Override
void endPlay() {
System.out.println("Football Game Finished!");
}
@Override
void initialize() {
System.out.println("Football Game Initialized! Start playing.");
}
@Override
void startPlay() {
System.out.println("Football Game Started. Enjoy the game!");
}
}
public class Main {
public static void main(String[] args) {
Game game = new Cricket();
game.play();
System.out.println();
game = new Football();
game.play();
}
}
模式模式的優點
- 1.利用模板模式將相同處理邏輯的代碼放到抽象父類中,可以提供代碼的可讀性
- 2.將不同的代碼放到不同的子類中,通過對子類的擴展增加新的行為,可以提高的擴展性
- 3.把不變的行為寫在父類,去除子類的重復代碼,提供了一個很好的代碼復用平臺,符合開閉原則.
8. 配接器模式詳解
配接器模式(Adapter Pattern)是指將一個類的介面轉換成客戶希望的另外一個介面,配接器模式使得原本由于介面不兼容而不能一起作業的那些類可以一起作業,
使用場景如下
- 1.已經存在的類和方法和需求不匹配(方法結果相同或相似)的情況
- 2.配接器模式不是軟體初始階段考慮的設計模式,是隨著軟體的發展,不同廠家造成的功能類似而介面不同的問題的解決方案,
此處以重構第三方登錄適配為例
老系統一般剛開始只有密碼登錄的系統,隨著社會的進步,單純的密碼登錄已經滿足不了廣大網友了,大部分系統已經支持多種登錄方式,如QQ登錄,微信登錄,手機登錄,微博登錄等.
//登錄介面
public class SiginService {
/**
* 注冊
*/
public ResultMsg regist(String username,String password){
return new ResultMsg(200,"注冊成功",new User());
}
/**
* 登錄
*/
public ResultMsg login(String username,String password){
return null;
}
}
//回傳結果封裝
public class ResultMsg {
private int code;
private String msg;
private Object data;
public ResultMsg(int code, String msg, Object data) {
this.code = code;
this.msg = msg;
this.data = data;
}
public int getCode() {
return code;
}
public void setCode(int code) {
this.code = code;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
public Object getData() {
return data;
}
public void setData(Object data) {
this.data = data;
}
}
/**
* @author Dominick Li
* @CreateTime 2021/1/18 22:29
* @description 定義登錄配接器規范
**/
public interface LoginAdapter {
boolean support(Object adapter);
ResultMsg login(Object [] param, Object adapter);
}
//QQ登錄
public class LoginForQQAdapter implements LoginAdapter {
@Override
public boolean support(Object adapter) {
return adapter instanceof LoginForQQAdapter;
}
@Override
public ResultMsg login(Object[] param, Object adapter) {
System.out.println("QQ登錄");
return null;
}
}
//手機號登錄
public class LoginForTelAdapter implements LoginAdapter {
@Override
public boolean support(Object adapter) {
return adapter instanceof LoginForTelAdapter;
}
@Override
public ResultMsg login(Object[] param, Object adapter) {
System.out.println("手機號登錄");
return null;
}
}
/**
* @author Dominick Li
* @CreateTime 2021/1/18 22:25
* @description 第三方登錄兼容介面
**/
public interface PassportForThird {
/**
* qq登錄
*/
ResultMsg loginForQQ(String id);
/**
* 手機號登錄
*/
ResultMsg loginForTelphone(String telphone,String code);
/**
* 注冊后自動登錄
*/
ResultMsg loginForRegist(String username,String password);
}
/**
* @description 第三方登錄兼容介面
**/
public interface PassportForThird {
/**
* qq登錄
*/
ResultMsg loginForQQ(String id);
/**
* 手機號登錄
*/
ResultMsg loginForTelphone(String telphone,String code);
/**
* 注冊后自動登錄
*/
ResultMsg loginForRegist(String username,String password);
}
public class PassportForThirdAdapter extends SiginService implements PassportForThird {
@Override
public ResultMsg loginForQQ(String id) {
return processLogin(new Object[]{id}, LoginForQQAdapter.class);
}
@Override
public ResultMsg loginForTelphone(String telphone, String code) {
return processLogin(new Object[]{telphone,code}, LoginForTelAdapter.class);
}
@Override
public ResultMsg loginForRegist(String username, String password) {
super.regist(username,password);
return super.login(username,password);
}
/**
* 簡單工廠模式
*/
private ResultMsg processLogin(Object [] param, Class<? extends LoginAdapter> clas) {
try {
LoginAdapter adapter = clas.newInstance();
if (adapter.support(adapter)) {
return adapter.login(param, adapter);
}
return null;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
public class Main {
public static void main(String[] args) {
PassportForThird passportForThird=new PassportForThirdAdapter();
passportForThird.loginForTelphone("12345","123");
}
}
配接器模式主要解決的是功能兼容問題
配接器模式在Spring原始碼中的使用
- 1.如Spring AOP中的AdvisorAdapter類,它有三個實作類: MethodBeforeAdviceAdapter,AfterReturningAdviceAdapter和ThrowsAdviceAdapter,源代碼如下

public interface AdvisorAdapter {
// 判斷此配接器是否支持特定的Advice
boolean supportsAdvice(Advice var1);
//將一個Advisor適配成MethodInterceptor
MethodInterceptor getInterceptor(Advisor var1);
}
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
MethodBeforeAdviceAdapter() {
}
public boolean supportsAdvice(Advice advice) {
return advice instanceof MethodBeforeAdvice;
}
public MethodInterceptor getInterceptor(Advisor advisor) {
MethodBeforeAdvice advice = (MethodBeforeAdvice)advisor.getAdvice();
return new MethodBeforeAdviceInterceptor(advice);
}
}
Spring會根據不同的AOP配置來使用對應的Advice,與策略模式不同的是,一個方法可以同時擁有多個Advice
- 2.在DispatcherServlet的doDispatch()方法中也有使用,在doDispatch()方法中呼叫了getHandlerAdapter()方法.原始碼如下
protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException {
if (this.handlerAdapters != null) {
Iterator var2 = this.handlerAdapters.iterator();
while(var2.hasNext()) {
HandlerAdapter adapter = (HandlerAdapter)var2.next();
//判斷是否兼容
if (adapter.supports(handler)) {
return adapter;
}
}
}
throw new ServletException("No adapter for handler [" + handler + "]: The DispatcherServlet configuration needs to include a HandlerAdapter that supports this handler");
}
配接器模式的優缺點
優點:
- 1.提高類的透明性和復用性,現有的類會被復用但不需要改變
- 2.目標類和配接器類解耦,可以提供程式的可擴展性
- 3.在很多業務場景中符合開閉原則
缺點:
- 1.在配接器代碼撰寫的程序中需要進行全面考慮,可能會增加系統的復雜度
- 2.增加了代碼的閱讀難度,降低了代碼的可讀性,過多使用配接器會使系統的代碼變得凌亂
9. 裝飾器模式
裝飾器模式(Decorator Pattern)是指在不改變原有物件的基礎上,將功能附加到物件上,提供了比繼承更有彈性的方案(擴展原有物件的功能),屬于結構性模式,裝飾者模式適用于以下場景
- 1.擴展一個類的功能或給一個類添加附加職責
- 2.動態給一個物件添加功能,這些功能可以再動態地撤銷
此處以賣煎餅為示例
public class Battercake {
protected String product() {
return "煎餅";
}
protected int getPrice() {
return 5;
}
@Override
public String toString() {
return product() + ",總價格:" + getPrice();
}
}
//加一個雞蛋
public class BattercakeWithEgg extends Battercake {
@Override
protected String product() {
return super.product()+"加1個雞蛋";
}
@Override
protected int getPrice() {
return super.getPrice()+1;
}
}
//加一個雞蛋和一個香腸
public class BattercakeWithEggAndSausage extends BattercakeWithEgg {
@Override
protected String product() {
return super.product()+"加1個香腸";
}
@Override
protected int getPrice() {
return super.getPrice()+2;
}
}
public class Main {
public static void main(String[] args) {
Battercake battercake = new Battercake();
System.out.println(battercake);
Battercake battercakeWithEgg = new BattercakeWithEgg();
System.out.println(battercakeWithEgg);
Battercake battercakeWithEggAndSausage = new BattercakeWithEggAndSausage();
System.out.println(battercakeWithEggAndSausage);
}
}

裝飾器模式和配接器模式對比
裝飾器模式和配接器模式都是(Wraooer Pattern),裝飾器模式也是一種特殊的代理模式,二者對比如下
| 列名 | 裝飾器模式 | 配接器模式 |
|---|---|---|
| 形式 | 是一種特別的配接器模式 | 沒有層級關系,裝飾器模式有 |
| 定義 | 裝飾者和被裝飾者實作同一個介面,主要目的是擴展之后依舊保留OOP關系 | 配接器和被適配者沒有必然的聯系,通常采用繼承或者代理的形式進行包裝 |
| 關系 | 滿足 is-a的關系 | 滿足has-a的關系 |
| 功能 | 注重覆寫,擴展 | 注重兼容,轉換 |
| 設計 | 前置考慮 | 后置考慮 |
- is-a : 表示類與類之間的繼承關系、介面與介面之間的繼承的關系以及類對介面實作的關系
- has-a: 是關聯關系的一種,是整體和部分(通常為一個私有的變數)之間的關系,并且代表的整體物件負責構建和銷毀代表部分
裝飾器模式在原始碼中的應用
在JDK中體現最多的就是I/O相關的類,如BufferedReader,InputStream,OutputStream
如下圖,FilterInputStream被3個子類參考了.

在Spring中的TransactionAwareCacheDecotator類中有被使用,這個類主要用于處理事務快取的,原始碼如下
public class TransactionAwareCacheDecorator implements Cache {
private final Cache targetCache;
public TransactionAwareCacheDecorator(Cache targetCache) {
Assert.notNull(targetCache, "Target Cache must not be null");
this.targetCache = targetCache;
}
}
TransactionAwareCacheDecorator就是對Cache的一個包裝.
裝飾器模式的優缺點
優點:
- 1.裝飾器模式是繼承的有力補充,且比繼承靈活,可以在不改變原有物件的情況下動態給一個物件擴展功能,即插即用.
- 2.使用不同的裝飾類及這些裝飾類的排列組合,可以實作不同的效果
- 3.裝飾器模式完全符合開閉原則
缺點:
- 1.會出現更多的代碼,更多的類,增加程式的復雜性
- 2.多層裝飾會更復雜
10.觀察者模式
觀察者模式(Observer Pattern)定義了物件之間的一對多依賴,讓多個觀察者物件同時監聽一個主體物件,當主體物件發生變化時,它的所有的依賴者(觀察者)都會受到通知并更新,屬于行為者模式,觀察者模式有時候也叫發布訂閱模式,例如我們生活中的郵件通知,桌面程式的事件回應等.
//監聽器的一種包裝,標注事件源格式的定義
public class Event {
//事件源,事件是由誰發起的,保存起來
private Object source;
//事件觸發,要通知誰
private Object target;
//事件觸發,要做什么動作,回呼
private Method callback;
//事件的名稱,觸發的是什么事件
private String trigger;
//事件觸發的時間
private long time;
public Event(Object target, Method callback) {
this.target = target;
this.callback = callback;
}
public Event setSource(Object source) {
this.source = source;
return this;
}
public Event setTrigger(String trigger) {
this.trigger = trigger;
return this;
}
public Event setTime(long time) {
this.time = time;
return this;
}
}
//監聽器,它就是觀察者的橋梁
public class EventListenter {
protected Map<String, Event> events = new HashMap<>();
//通過事件名稱和一個目標物件來觸發事件
public void addLisenter(String eventType, Object target) {
try {
this.addLisenter(eventType, target, target.getClass().getMethod(eventType, Event.class));
} catch (Exception e) {
e.printStackTrace();
}
}
public void addLisenter(String eventType, Object target, Method callback) {
//注冊事件
events.put(eventType, new Event(target, callback));
}
//觸發
private void trigger(Event event) {
event.setSource(this);
event.setTime(System.currentTimeMillis());
try {
//發起回呼
if (event.getCallback() != null) {
//用反射呼叫它的回呼函式
event.getCallback().invoke(event.getTarget(), event);
}
} catch (Exception e) {
e.printStackTrace();
}
}
protected void trigger(String trigger){
if(!this.events.containsKey(trigger)){return;}
trigger(this.events.get(trigger).setTrigger(trigger));
}
}
//定義事件型別
public interface EventType {
String CLICK="click";
}
/**
* @author Dominick Li
* @CreateTime 2021/1/19 22:37
* @description 回呼函式類
**/
public class MouseEventCallback {
public void click(Event e){
System.out.println("==============觸發滑鼠點擊事件===============\n"+e);
}
}
//被觀察者
public class Mouse extends EventListenter {
public void click(){
System.out.println("呼叫單機事件");
this.trigger(EventType.CLICK);
}
}
public class Main {
public static void main(String[] args) {
MouseEventCallback callback=new MouseEventCallback();
//注冊事件
Mouse mouse=new Mouse();
mouse.addLisenter(EventType.CLICK,callback);
//呼叫方法
mouse.click();
}
}
觀察者模式在原始碼中的應用
Spring中的ContextLoaderListener類實作了ServletContextListener介面,ServletContextListener又繼承了EventListener介面
public class ContextLoaderListener extends ContextLoader implements ServletContextListener {
public ContextLoaderListener() {
}
public ContextLoaderListener(WebApplicationContext context) {
super(context);
}
public void contextInitialized(ServletContextEvent event) {
this.initWebApplicationContext(event.getServletContext());
}
public void contextDestroyed(ServletContextEvent event) {
this.closeWebApplicationContext(event.getServletContext());
ContextCleanupListener.cleanupAttributes(event.getServletContext());
}
}
public interface ServletContextListener extends EventListener {
default void contextInitialized(ServletContextEvent sce) {
}
default void contextDestroyed(ServletContextEvent sce) {
}
}
public interface EventListener {
}
基于Guava API輕松實作觀察者模式
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>30.1-jre</version>
</dependency>
public class GuavaEvent {
@Subscribe
public void subscribe(String str){
System.out.println("執行subscribe方法,傳入的引數是"+str);
}
}
public class Main {
public static void main(String[] args) {
EventBus eventBus=new EventBus();
GuavaEvent guavaEvent=new GuavaEvent();
eventBus.register(guavaEvent);
eventBus.post("我喜歡你");
}
}
觀察者模式的優缺點
優點
- 1.在觀察者和被觀察者之間建立了一個抽象的耦合
- 2.觀察者模式支持廣播通信
缺點
- 1.觀察者之間有過多的細節依賴,時間消耗多,程式的復雜性更高
- 2.使用不當會出現回圈呼叫
三.GoF23種設計模式簡介
| 分類 | 設計模式 |
|---|---|
| 創建型 | 工廠方法模式,抽象工廠模式,建造者模式,原型模式,單例模式 |
| 結構型 | 配接器模式,橋接模式,組合模式,裝飾者模式,門面模式,享元模式,代理模式 |
| 行為型 | 解釋器模式,模板方法模式(模板模式),責任鏈模式,命令模式,迭代器模式,調節者模式,備忘錄模式,觀察者模式,狀態模式,策略模式,訪問者模式. |
設計模式直接的關聯關系

| 模式組合 | 描述 |
|---|---|
| 單例模式和工廠模式 | 在實際使用中,會把工廠類設定為單例模式 |
| 策略模式和工廠模式 | 工廠模式包含工廠方法模式和抽象工廠模式,是創建型模式,策略模式屬于行為者模式,工廠模式的主要目的是封裝好創建邏輯,策略模式接受工廠創建好的物件,從而實作不同的行為 |
| 策略模式和委派模式 | 策略模式是委派模式內部的一種實作方式,測驗模式關注結果是否能相互替代,委派模式更關注分發和調度的程序 |
| 模板方法模式和工廠方法模式 | 工廠方法模式是模板方法模式的一種特殊實作,對于工廠方法模式的create()方法而言,工廠方法模式相當于只有一個步驟的模板方法模式,這個步驟交給子類實作, |
| 模式方法模式和策略模式 | 模板方法模式和策略模式都有封裝演算法,策略模式使不同演算法可以相互替換,且不影響客戶端應用,使用模板方法模式針對定義一個演算法的流程,將一些有細微差異的部分交給子類實作,模板方法模式不能改變演算法流程,策略模式可以 |
| 裝飾者模式和代理模式 | 裝飾者模式的關注點在于給物件動態添加方法,而代理模式根加注重控制物件的訪問,代理模式通常會在代理類中創建被代理類物件的實體,二裝飾者模式通常會把裝飾者作為構造引數 |
| 裝飾者模式和配接器模式 | 裝飾者模式和配接器模式都屬于包裝模式 (Wrapper Pattern),裝飾者模式可以試下與被裝飾者相同的介面,或者繼承被裝飾者作為它的子類,而配接器和被配接器著都可以實作不同的介面. |
| 配接器模式和靜態代理模式 | 配接器模式可以結合靜態代理模式來實作,保存被適配物件的參考 |
| 配接器模式和策略模式 | 在業務復雜的情況下可以用策略模式優化器配接器模式 |
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/292023.html
標籤:java
