定義:裝飾模式屬結構型設計模式。動態地給一個物件新增一些額外的職責,就增加功能來說,裝飾模式比生成子類更為靈活。
以下以王者榮耀中橘右京,普通攻擊以及帶有紅BUFF的攻擊為例。
裝飾模式結構圖
在裝飾模式中有如下角色:
- IAttack:攻擊的介面類
- AbstractAttact:實現了攻擊介面的抽象類,其持有被裝飾類的引用
- RedBuff:紅buff,AbstractAttact的實現類,裝飾類
- OrangeYouJing:橘右京,被裝飾類
程式碼:
public interface IAttack {
void attack();
}
public abstract class AbstractAttact implements IAttack {
private IAttack mAttact;
public AbstractAttact(IAttack attack) {
mAttact = attack;
}
@Override
public void attack() {
mAttact.attack();
}
}
public class RedBuff extends AbstractAttact {
public RedBuff(IAttack attack) {
super(attack);
}
@Override
public void attack() {
super.attack();
attackWithBuff();
}
private void attackWithBuff(){
System.out.println("帶有紅buff的攻擊");
}
}
public class OrangeYouJing implements IAttack {
@Override
public void attack() {
System.out.println("橘右京削橘子");
}
}
public class DecoratorTest {
private OrangeYouJing mOrangeYouJing;
private RedBuff mRedBuff;
@Before
public void setUp() throws Exception {
mOrangeYouJing = new OrangeYouJing();
mRedBuff = new RedBuff(mOrangeYouJing);
}
@Test
public void attack() throws Exception {
mRedBuff.attack();
}
}
複製程式碼
使用場景
- 在不影響其他物件的情況下,以動態、透明的方式給單個物件新增職責。
- 需要動態地給一個物件新增功能,這些功能可以動態的撤銷。
- 當不能採用整合的方式對系統進行擴充或者採用整合不利於系統擴充和維護時。
優點:
- 通過組合而非整合的方式,動態地擴充套件一個物件的功能,在執行時選擇不同的裝飾器,從而實現不同的行為。
- 有效避免了使用整合的方式擴充物件功能而帶來的靈活性差,子類無限制擴張的問題。
- 具體元件類與具體裝飾類可以獨立變化,使用者可以根據需要增加新的具體元件類和具體裝飾類,在使用時再對其進行組合,原有程式碼無需改變,符合“開放閉合原則”。
缺點:
- 比整合更加靈活激動的特性,也同時意味著裝飾模式比整合更加易於出錯,排錯也很困難。對於多次裝飾的物件,除錯時宣召錯誤可能需要逐級排查,較為繁瑣。所以,只在必要的時候使用裝飾模式。
- 裝飾層數不能過多,否則會影響效率。
程式碼已上傳github