【正文】 }。 } }。 public: DoorTimerAdapter(TimedDooramp。 class DoorTimeAdapter:public TimerClient{ TimedDooramp。 TimedDoor的多個(gè)超時(shí)請(qǐng)求問題，導(dǎo)致 Timer接口做出下面的調(diào)整： TimedDoor對(duì) Timer接口的影響會(huì)傳遞到 Door接口，從而導(dǎo)致所有 Door都受到此影響，而且這一影響還會(huì)影響到 Door的所有 Clients——牽一發(fā)動(dòng)全身 ? 解決之道： – 使用委托 T i m e r i n t e r f a c e T i m e r C l i e n t+ T i m e o u tD o o r T i m e r A d a p t e r+ T i m e o u tT i m e d D o o r+ D o o r T i m e O u tD o o r C r e a t e s Class TimedDoor:public Door{ public: virtual void DoorTimeOut(int timeOutID)。 class TimerClient{ public: virtual void TimerOut(int timeOutId )。 胖接口將導(dǎo)致 SRP， LSP被違反，從而導(dǎo)致脆弱、僵化 ? 客戶的反作用力： – 通常接口的變化將導(dǎo)致 client的改變 – 但是很多時(shí)候，接口之所以變化是因?yàn)榭蛻粜枰麄冏兓? ? Client對(duì) interface具有反作用力！ class Timer{ public: void Register(int timeout, int timeOutId, TimerClient* client)。 ?該函數(shù)有兩個(gè)參數(shù)，一個(gè)是超時(shí)時(shí)間，另一個(gè)是指向TimerClient對(duì)象的指針，此對(duì)象的 TimerOut函數(shù)會(huì)在超時(shí)時(shí)被調(diào)用 我們?nèi)绾螌?TimerClient和 TimedDoor聯(lián)系起來？ 問題 一種常見的解決方案如下： T i m e r i n t e r f a c e T i m e r C l i e n tD o o r+ T i m e o u tT i m e d D o o r?問題 ——接口污染 在 Door接口中加入新的方法（ Timeout），而這個(gè)方法僅僅只為它的一個(gè)子類帶來好處。 }。 }。 ? Door可以加鎖、解鎖、而且可以感知自己是開還是關(guān)； ? Door是抽象基類，客戶程序可以依賴于抽象而不是具體的實(shí)現(xiàn) 增加功能 如果門打開時(shí)間過長，它就會(huì)報(bào)警。 virtual bool IsDoorOpen( )=0。 ? 先說一個(gè)例子： class Door{ public: virtual void Lock( )=0。 Button依賴于 ButtonServer接口，但是接口并不依賴于 Button，也就是說任何知道如何操作 ButtonServer接口的對(duì)象都可以操作 Lamp。 質(zhì)疑： – 這樣的設(shè)計(jì)是不是強(qiáng)加了這樣一個(gè)約束 ——所有需要被 Button控制的對(duì)象一定要實(shí)現(xiàn) ButtonServer類。 }。 // class Lamp:public ButtonServer{ public: void turnOn()。 virtual void turnOff()=0。 else if((/* mechanism for detecting turnOff mand */) bsturnOff( )。 }。 部分代碼： // include class Button{ ButtonServer * bs。 ButtonServer提供一些抽象的方法， Button類通過這些接口可以開啟或關(guān)掉一些東西。 public: void poll( ){ if(/* some condition */) itsLampturnOn( )。 當(dāng)接受到 Poll（輪詢）消息時(shí)，判斷其是否被 “ 按下 ” 。 } p( ){ g( )。 ” ——Booch – 對(duì)上述論述可能存在兩種不同的理解： ? 簡單的理解 P o l i c y L a y e rM e c h a n i s m L a y e rU t i l i t y L a y e ru1( ) u2( ) g( ){ u1()。低層通常是易變的。通常改變一個(gè)軟硬件平臺(tái)將導(dǎo)致一些具體的實(shí)現(xiàn)發(fā)生變化，如果高層依賴低層，這種變化將導(dǎo)致逐層的更改。 – 高層包含應(yīng)用程序的策略和業(yè)務(wù)模型，而低層包含更多的實(shí)現(xiàn)細(xì)節(jié)，平臺(tái)相關(guān)細(xì)節(jié)等。細(xì)節(jié)應(yīng)該依賴于抽象。二者應(yīng)該依賴于抽象。在 Jave和 C＋＋標(biāo)準(zhǔn)中尚未支持，我們必須自己考慮。 ?派生類必須接受基類已經(jīng)接受的一切；并且，派生類不能違反基類已經(jīng)確定的規(guī)則。 (itsHeight==))。 ? 基于契約（和約）的設(shè)計(jì) ——DBC（ Deign by Contract）（續(xù)） – 例如： 在上面的例子中， Rectangle::SetWidth(double w)的后置條件可以看作是： assert((itsWidth==w) amp。 – 契約通過為每一個(gè)方法規(guī)定前置條件（ preconditions）和后置條件（ postconditions）來指定的。 ——我怎么知道是否合理呢？？ – 使用 DBC，類的編寫者需要顯示的規(guī)定針對(duì)該類的契約。 ?而行為可以依賴客戶程序做出合理的假設(shè)。直到出現(xiàn)問題的時(shí)候我們才解決它。 assert(()==20)。 r){ (5)。 }。 void Square::setHeight(double h){ Rectangle::setWidth(h)。 Rectangle::setHeight(w)。 }。 class Square:public Rectangle{ public: void setWidth(double w)。} double getHeight() const{return height。} virtual void setHeight(double h){height=h。 double height。 } 問題： 顯然，當(dāng)我們將一個(gè) Square的實(shí)例傳給 f時(shí)，將可能導(dǎo)致其 height與width不等，破壞了其完整性 ——違反了 LSP 要改正上述問題，很簡單，我們只要將 SetWidth和 SetHeight兩個(gè)函數(shù)設(shè)置成virtual函數(shù)即可 ——添加派生類需要修改基類，通常意味著設(shè)計(jì)上的缺陷 但是并非所有人都同意上述的分析 反方：真正的設(shè)計(jì)缺陷是忘記把 SetWidth和 SetHeight兩個(gè)函數(shù)作為 virtual函數(shù) 正方：設(shè)置長方形的長寬是非常基本的操作，不是預(yù)見到有正方形這樣的派生類，怎么會(huì)想到要將其設(shè)成虛函數(shù)？ – 放下這個(gè)爭論，我們先將 SetWidth和 SetHeight改作虛函數(shù)看看 class Rectangle{ Point topLeft。 R e c ta n g leS q u a r e– 問題的第一步分析： ? 看下面這個(gè)函數(shù) void f(Re