上回的最后，來了兩個用戶，分別提出了兩個不同的需求。一個要求用兩個開關控制一個燈，一個要求用一個開關控制所有的燈。本回將就這兩個需求進行分析。我寫這段話的時候并沒有想出這個需求的具體方案，重要的過程，思路有時候比結果更重要。所以，我的方案可能會"跑偏"；但是如果你能從過程中體會到些什么，那這篇就沒有白寫。

兩個開關控制一個燈。這個問題好像很簡單，把兩個Switcher的Switchee都設置為同一個燈不就結了嗎？畫個對象圖會是這個樣子。

 
圖1 由雙開關控制的燈

有問題嗎？

用戶的真實需求

考慮一下這個問題。如果你用Switcher1開了燈，再去開一下Switcher2，燈應該是保持開著還是關了呢？從技術人員的角度來講，調用的Switcher的開，當然應該保持開啦。但是策劃會說，這兩個開關應該是相互作用的，還拿出了電路圖給我看。這是的確是張真實情況下的雙開關電路圖。

 
圖2 雙路開關電路

Switcher1的開關，撥到左邊是開還是關，取決于Switcher2現在是撥在左邊兒還是右邊。電路圖的天然連通性就自然而然地做到了這一點。現實中的Switcher1不會去問Switcher2：嘿，哥們，你現在是個啥狀態？而我們的代碼中的兩個Switcher間也不應該有什么交集。

總而言之，在這個需求的要求下，用戶要做的，就是撥一下開關而已（圖3中JustSwitch方法的作用）。

對當前設計的改進

在以上需求的約束下，就第一篇開始所寫的Switcher而言，就會存在著一個問題。先不說雙開關，單單一個開關我們的設計就是不符合產品策劃的要求。因為之前寫的Switcher類是有兩個函數作開關控制的。

public class Switcher   
 
{   
 
    public ISwitchable Switchee { get; set; }   
 
    public void TurnOn() { Switchee.TurnOn(); }   
 
    public void TurnOff() { Switchee.TurnOff(); }   
 
}   

代碼1

這是有問題的。因為Switcher是直接給用戶用的。你覺得用戶是想用哪種開關呢？

是 還是 呢？

總不能讓用戶根據現在燈是開著還是關著讓用戶按不同的按鈕。（使用不同的函數。）所以Switcher的代碼應該是這個樣子的。

public class Switcher   
{   
    private bool isOn;   
    public ISwitchable Switchee { get; set; }   
 
  public void JustSwitch()   
  {   
    // 根據當前狀態選擇正確的操作。   
    if (isOn)   
    {   
        Switchee.TurnOff();   
        isOn = false;   
    }   
    else   
    {   
        Switchee.TurnOn();   
        isOn = true;   
    }   
  }   
}  

代碼2

Switcher自己保存最后一次操作的結果（當前狀態），并自動選擇正確的操作。

支持雙開關

當每個燈只有一個開關的時候，這個代碼沒有任何問題。但是出現兩個開關的話就沒這么好辦了，自己保存的狀態是無效的，可能會被另一個開關改掉。如果要達到和電路圖一樣的效果，Switcher1要么問Switcher2現在是什么狀態，要么問Light是什么狀態。

直覺上，問Switcher2這事兒不是個好選擇，因為以后還可能會有Switcher3、4。但燈就一個。但是等等，我們現在的接口是什么樣的？

 
圖3. 現在的設計

ISwitchable接口只定義了TurnOn和TurnOff兩個函數，沒有可以用于查詢燈的當前狀態的方法。這太糟糕了，這意味著接口要改了。改接口永遠是最糟糕的事情。《軟件框架設計的藝術》里說"API就如同恒星，一旦出現，便與我們永恒存在。"，聽上去接口寫了就不能改，但是我們的情況要好很多，這個接口是公司自己定義的，沒有別人用過。所以改改無妨。J只要小小的加一個方法就可以了。

 
圖4. 添加查詢接口以支持雙開關

Switcher的代碼會是這樣的。Switcher暴露給用戶的應該只有 一個接口。

public interface ISwitchable   
{   
    void TurnOn();   
    void TurnOff();   
    bool IsOn();   
}  
   
public class Switcher   
{   
    public ISwitchable Switchee { get; set; }   
 
    public void JustSwitch()   
    {   
        // 根據當前狀態選擇正確的操作。   
        if (Switchee.IsOn())   
            Switchee.TurnOff();   
        else   
            Switchee.TurnOn();   
    }   
}  

代碼3

#p#

另一個極品方案

軟件開發與建筑施工的最大區別是，軟件開發可以選擇先蓋地下室還是天花板。

——我

當我們把要做的事情抽象一下，就能很容易地從更高的層次思考問題。比如上面，開關要知道燈的狀態。可以抽象為：

 
圖5. 開關開燈例子的高度抽象

各位可以想到什么設計上的問題？比較明顯的問題有兩個。

• 拉模式 VS推模式。既然圖中為拉模式，那么另一個思路就是推模式。也許你聽說一個說法，就是推模式比拉模式要好。但是如果真把推模式用在開關開燈的例子上，就成了燈的亮與熄，要去通知開關，以便開關下次Switch的時候，能做出正確地動作。想到這里，我邪惡地笑了。這得多蛋痛啊？模式的應用，永遠要看上下文。為了撫慰一些推模式死忠們脆弱的心靈，下面會介紹一個可行的推模式開燈設計。
• A 依賴B。雖然我們有ISwitchable接口，開關不直接依賴燈，但是你看，我們為什么要在ISwitchable接口里加入IsOn函數呢？因為開關需要知道燈的狀態。所以說，他們之間不但存在著依賴，而且還直接決定了接口的定義。但是與我第一篇文章中介紹的DIP原則是否沖突呢？這取決于你對開關的定位。如果只是單純的開關，那么IsOn函數的引入，就是對燈的功能的抽象，也就違反了DIP原則；如果你希望開關有點兒AI，那么顯然它得知道更多的信息（但是這違反了單一責任原則）。所以看上去，無論從哪個角度來講，IsOn的引入都是要違反XXXX原則的。

好，為了不違反所有現有的原則。構想出設計出如下的設計：

 
圖6. 引入AI系統對開關操作進行決策（拉模式）

理智一些吧，我們的開關公司沒有上市，既沒有資本做AI系統，也沒有卡馬克這種不要錢只要漢堡和網絡的技術狂人，我們的用戶也不會像暗黑的死忠一樣傻等 10年，然后等到一個需要接網線才能使用的電燈開關還能用得很愉悅。在這個發展階段要做的，只是盡快滿足當前的需求。

在達成需求前，技術方案的完美度，永遠是第二位的。第一位的，是有效率地執行 + 新穎的思路和方向。思路放后面，是因為對99.9%的情況來說，最不值錢的就是點子，你能想到的，別人可能都已經做出來了。即使是Jobs這種用新意折服世界的人，也要靠"現實扭曲力場"的幫助把自己的觀點有效地推行下去。

所以，這個方案雖然很不錯，但是我不愿意繼續討論了，因為這在現實中沒有意義，脫離現實的例子也就不再是好例子了。

我還想說一句，做項目和做人，都不能走極端。另一個極端是：以敏捷之名，無視一切編碼前的設計。我猜這在群人眼中，這個系列的文章沒有任何意義。

———————————————————牢騷的休止符—————————————————————

再一個方案

有人可能會說，讓燈自己控制自己的狀態，也可以解決問題。像下面這樣。

 
圖7 另一種解決方案

然后把Light類實現成這個樣子：（多酷啊，目前為止代碼量最少的方案）

public class Light : ISwitchable   
{   
    private bool isGlowing;   
    public void JustSwitch()   
    {   
        isGlowing = !isGlowing;   
    }   
}  

代碼 4

這個設計的確可行，但是哪個方案更好呢？這個問題就留給各位讀者吧。就拿幾個Principle逐個分析下應該就可以分析出個所以然來。（下一節有簡單提示）

設計思想（原則）及技術方案的濫用

每種設計都有他的思路和道理。你覺得不可理喻的設計可能恰恰是別人深思熟慮的結果，只是每個人的思路不一樣，結果自然也不相同。但是如果設計思路被某種設計思想占據了絕對主導的地位，就可能會出現設計上的偏差。

我把濫用大體上總結成如下三種：

1. 單純的濫用。因為我會這么做，所以就順便這么做了。他們的理論基礎是：雖然現在沒有這要的需求，誰知道以后有沒有呢？我多做一點兒還不好？最典型的癥狀是，所有的類，都有相應的接口，全部使用Dependency Injection來實例化。這不是有病么？

   這會引出一個比較大的話題，就是怎樣的設計算是過度設計？這需要單獨寫一節來討論這個問題。就不在這里展開了。

2. 程度上的濫用。圖7的設計，就體現了一個叫做"Tell, Don't Ask"的原則，或者說是為了將這個原則"發揮到極致"而形成的設計。而在這個原則之下寫出的代碼4又是如此簡潔和優美；以至于讓想出這個方案的人，很難主動拋棄這個方案。直到看到這個方案不能滿足的需求才肯承認問題。
3. 適用范圍濫用。把某個原則或是技術方案當萬金油。只要能用得上，就一定要用上一用。導致一葉蔽目，不愿意尋求其它更加合適的技術方案（項目時間緊是個最常見的借口，一知道某個方案可行，就馬上付諸行動）。一時興起，畫了個漫畫。

 
圖8. 因為熟悉或懶惰而舍近求遠

第一篇就說過，優秀的設計不是藉由幾個原則、模式就可以保證的。何況是某一個原則呢？物極必反。今天就不再啰嗦了。大家也都懂。設計過程中對某個特定的設計思想或是技術過于執著，往往會形成一個雖可行、卻畸形的設計。圖7即是一個例子。

#p#

一個真實的案例

有一家著名的咨詢公司，2009年接了一個銀行的大單，為期一年，預計可以賺到五個億。但是這個項目現在都還沒有結束，項目延期不僅要給銀行賠償，還要繼續免費給銀行把這個項目做完。（想想國內公司會怎么做？）2010-2011年度，公司接的其它項目賺的錢幾乎全部貼給了這個項目。當年全公司員工沒有獎金，部分相關高層降職降薪。

為什么？一個可以賺到五個億的項目卻虧了幾個億？

目前項目內員工的工作效率極低，一個普通開發者要兩天才能完成一個報表的修改。（現階段是修改，不是全新開發）。所以說人員成本非常大。項目拖上一個月，數百萬就打了水漂。

那么效率為什么這么低？他們所有的業務邏輯都用PL-SQL實現，大的報表，涉及到的PL-SQL動輒上萬行，而且層層調用，加之整個系統有數千個表。代碼的測試，都要先去數據庫造假數據。效率能高就怪了。

為什么要這么搞？因為一開始做系統設計的人，對PL-SQL比較熟悉，對Java不熟悉，所以就把Java當成了UI Wrapper來用。狗屎吧。當然還會有很多其它的因素，但是在技術層面，這絕對是重要因素之一。因為自己對某個技術比較熟悉，而不愿意在項目中了解和應用更適合的其它技術方案的人套上CTO之類的外衣，恒等于攪屎棍。

支持開關控制多個燈

簡單而言，要讓一個開關去控制所有的燈。聽上去很簡單，而且有很多種實現方式。但是如果仔細想想，會發現有很多問題。

需求分析，不同于簡單的需求整理

用戶給出的需求總會是很概括甚至模糊的，不是用戶懶得說，而是用戶覺得自己已經說清楚了。以開燈為例，用戶需求就是："要有一個統一開關。"，你如果再去追問用戶，要怎么個統一法？用戶可能就會不高興了，因為他覺得這是你應該解決的問題。但是如果簡單地把"要有統一開關"這個用戶需求直接寫進需求文檔的話，就等著項目失敗或是延期吧。

需求分析的第一步，就是要對用戶的需求進行分解、細節，找出合理用例。比如：用戶要求的是，要有統一開關，但是并沒有說每個燈就沒有自己的開關。如果每個燈又都有自己的開關，統一開關應該如何與各個專屬開關協作呢？從這個角度，就可以找到一些用例。

1. 兩個燈，都開著。這時去按統一開關，應該是全關對吧。也就是說，統一開關應該知道當前燈的狀態。并按當前燈的狀態去執行操作。
2. 三個燈，兩個開著。這時去按統一開關呢？統一開關的意思就是要有統一的行為，用戶肯定不會希望這個統一開關的行為是：把開著的燈關掉，把關著的燈打開。怎么辦？統計現在開著的比率？開著的多就全關？那如果是兩個燈，一個開著，一個關著呢？還有一個辦法是，讓統一開關使用代碼2的方案：自己記住上次的操作結果。上次是全關，這次就全開；反之亦然。

也就是說，用例1和用例2都是合理的，但卻是沖突的。這種沖突甚至是一種邏輯上的沖突，已經不是技術局限性的問題了。這種情況，在軟件開發中也是很常見的。這時，我們拿著自己的分析、自己的想法去詢問用戶的意見，用戶就會很樂意了。人們都喜歡做選擇題，而不是做問答題。不是么？

現實中的電路

現實中的電路圖有兩種做法。（非標準電路，請意會。強弱電相關專業也許可以參考這里）

 
圖9. 現實中的兩種簡單的總控加分支開關電路

前一張圖，分支開關有絕對的控制權；后一張圖中開關中有一個二極管，開關的開合用于控制二極管的極性，總開關的作用就是：把開著的關掉，把關著的打開。

看上去就是兩種開關嘛。

基于派生類的方案

為了讓一個開關可以控制多個燈，對現有程序設計上的改動很小。類圖如下：

 
圖10. 多控開關設計

通過派生新的Switcher，來提供不同的功能。在當前的需求下，這個方案是可行的。未來的需求，就留給未來去解決吧。

小結

本節本來是想講講需求決定設計這個理念，從兩個需求引出兩個互不兼容的設計方案。所以找了兩個需求一起講，但是最后這兩個需求并沒多大的沖突，也就沒有達到預期的目標。不過想說的倒是說出來了。就是項目的設計，最終還是要依賴于需求，任何要做出能夠適應未來需求的設計的想法，都是不切實際、勞民傷財的。（不知道有多少人會把這句話曲解為"設計無用論"，如果我認為設計無用，還會寫這個系列嗎？）

這個系列并不是要講設計模式，也不是用小例子做各種分析。只是想通過最簡單的例子講一些大道理（原則）。如果沒有合適的大道理可說，分析出一百個需求、做出一百個設計，也只是魚，而非我想說的漁。

距上節的發布也已經很久了，因為每回發表時，都會先想好下回寫什么、怎么寫，并結尾留個引子。這次很可惜，想好了下回寫什么，卻死活想不出合適的、簡單的需求來引出這個問題，也就不知道怎么寫了。所以下回什么能寫好我也不知道。大體上，也許還會有下而一些道理希望能和大家分享：

• 過度設計及關于"過度"的度量。
• 局部設計最優化與全局次優化之間的權衡。
• 什么是設計經驗及如何正確地借鑒。

新的用戶

     下一回講哪個還沒有講好，但是用戶的需求卻如潮水般涌來。先權且記下：

• 在開關上加一個小燈，表示現在的燈是開還是關。（因為開關和燈可能并不在一起）
• 通過開關調節燈的亮度。
• 在開關上顯示燈的耗電量、溫度、預期壽命等。
• 定時開關。
• 開關聲控、手勢控。
• 開關權限控制。

原文鏈接：http://www.cnblogs.com/nankezhishi/archive/2012/08/18/2645562.html