使用裝飾器模式做類的增強

我們已經實現了使用者註冊功能，現在想增加日誌記錄功能。具體來講就是在使用者註冊前後，分別輸出一條日誌。我們當然可以修改原有的業務**。

現在換個角度來問兩個問題：

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...