我們已經實現了使用者註冊功能,現在想增加日誌記錄功能。具體來講就是在使用者註冊前後,分別輸出一條日誌。我們當然可以修改原有的業務**。
現在換個角度來問兩個問題:
1. 團隊開發中,我們很可能根本拿不到源**,那又怎麼去增加這個功能呢?
2. 這次需求是增加日誌,以後再增加其他需求(比如異常處理),是不是仍然要改業務類呢?
總結一下:
我們要在不修改原有類業務**的前提下,去做類的增強。我們的設計要符合物件導向的原則:對擴充套件開放,對修改封閉!
都有哪些辦法呢?我們嘗試以下幾種方法:
業務模型
介面設計namespace testaopbydecorator
public
int id }}
業務實現namespace testaopbydecorator
}
上層呼叫using system;
namespace testaopbydecorator
console.writeline(string.format("註冊了乙個使用者:", user.id, user.name));}}
}
裝飾器類using system;
namespace
testaopbydecorator
; static
void main(string args)
private
static
void register()}}
上層呼叫using system;
namespace testaopbydecorator
public
void
registeruser(user user)
before(user);
this._processor.registeruser(user);
after(user);
}private
void
after(user user)
private
void
before(user user)}}
對比一下擴充套件前後的業務展現using system;
namespace
testaopbydecorator
; static
void main(string args)
private
static
void registerandlog()}}
函式作裝飾器 ,類做裝飾器
用類寫裝飾器 func decorator func func abc 18 class decorator object def init self,f self.f f def call self,args,kwargs print decorator start self.f args,kwa...
設計模式 裝飾器模式的使用
問題 我們在進行軟體系統設計的時候,有一些業務 如下圖,一些通用的非功能性需求 是多個模組都需要的,是跨越模組的。把它們放到什麼地方呢?最簡單的辦法就是把這些通用模組的介面寫好,讓程式設計師在實現業務模組的時候去呼叫。這樣做的缺點是,日誌 安全 事務 統計效能等相關 幾乎把真正的業務 淹沒了。重複的...
類的裝飾器
def deco obj obj.x 1 obj.y 2 return obj deco 相當於foo deco foo class foo pass print foo.dict deco 相當於test deco test def test pass print test.dict 輸出 def...