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

兩個(gè)開關(guān)控制一個(gè)燈。這個(gè)問題好像很簡單，把兩個(gè)Switcher的Switchee都設(shè)置為同一個(gè)燈不就結(jié)了嗎？畫個(gè)對(duì)象圖會(huì)是這個(gè)樣子。

 
圖1 由雙開關(guān)控制的燈

有問題嗎？

用戶的真實(shí)需求

考慮一下這個(gè)問題。如果你用Switcher1開了燈，再去開一下Switcher2，燈應(yīng)該是保持開著還是關(guān)了呢？從技術(shù)人員的角度來講，調(diào)用的Switcher的開，當(dāng)然應(yīng)該保持開啦。但是策劃會(huì)說，這兩個(gè)開關(guān)應(yīng)該是相互作用的，還拿出了電路圖給我看。這是的確是張真實(shí)情況下的雙開關(guān)電路圖。

 
圖2 雙路開關(guān)電路

Switcher1的開關(guān)，撥到左邊是開還是關(guān)，取決于Switcher2現(xiàn)在是撥在左邊兒還是右邊。電路圖的天然連通性就自然而然地做到了這一點(diǎn)。現(xiàn)實(shí)中的Switcher1不會(huì)去問Switcher2：嘿，哥們，你現(xiàn)在是個(gè)啥狀態(tài)？而我們的代碼中的兩個(gè)Switcher間也不應(yīng)該有什么交集。

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

對(duì)當(dāng)前設(shè)計(jì)的改進(jìn)

在以上需求的約束下，就第一篇開始所寫的Switcher而言，就會(huì)存在著一個(gè)問題。先不說雙開關(guān)，單單一個(gè)開關(guān)我們的設(shè)計(jì)就是不符合產(chǎn)品策劃的要求。因?yàn)橹皩懙腟witcher類是有兩個(gè)函數(shù)作開關(guān)控制的。

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

代碼1

這是有問題的。因?yàn)镾witcher是直接給用戶用的。你覺得用戶是想用哪種開關(guān)呢？

是 還是 呢？

總不能讓用戶根據(jù)現(xiàn)在燈是開著還是關(guān)著讓用戶按不同的按鈕。（使用不同的函數(shù)。）所以Switcher的代碼應(yīng)該是這個(gè)樣子的。

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

代碼2

Switcher自己保存最后一次操作的結(jié)果（當(dāng)前狀態(tài)），并自動(dòng)選擇正確的操作。

支持雙開關(guān)

當(dāng)每個(gè)燈只有一個(gè)開關(guān)的時(shí)候，這個(gè)代碼沒有任何問題。但是出現(xiàn)兩個(gè)開關(guān)的話就沒這么好辦了，自己保存的狀態(tài)是無效的，可能會(huì)被另一個(gè)開關(guān)改掉。如果要達(dá)到和電路圖一樣的效果，Switcher1要么問Switcher2現(xiàn)在是什么狀態(tài)，要么問Light是什么狀態(tài)。

直覺上，問Switcher2這事兒不是個(gè)好選擇，因?yàn)橐院筮€可能會(huì)有Switcher3、4。但燈就一個(gè)。但是等等，我們現(xiàn)在的接口是什么樣的？

 
圖3. 現(xiàn)在的設(shè)計(jì)

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

 
圖4. 添加查詢接口以支持雙開關(guān)

Switcher的代碼會(huì)是這樣的。Switcher暴露給用戶的應(yīng)該只有 一個(gè)接口。

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

代碼3

#p#

另一個(gè)極品方案

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

——我

當(dāng)我們把要做的事情抽象一下，就能很容易地從更高的層次思考問題。比如上面，開關(guān)要知道燈的狀態(tài)?？梢猿橄鬄椋?/p>

 
圖5. 開關(guān)開燈例子的高度抽象

各位可以想到什么設(shè)計(jì)上的問題？比較明顯的問題有兩個(gè)。

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

好，為了不違反所有現(xiàn)有的原則。構(gòu)想出設(shè)計(jì)出如下的設(shè)計(jì)：

 
圖6. 引入AI系統(tǒng)對(duì)開關(guān)操作進(jìn)行決策（拉模式）

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

在達(dá)成需求前，技術(shù)方案的完美度，永遠(yuǎn)是第二位的。第一位的，是有效率地執(zhí)行 + 新穎的思路和方向。思路放后面，是因?yàn)閷?duì)99.9%的情況來說，最不值錢的就是點(diǎn)子，你能想到的，別人可能都已經(jīng)做出來了。即使是Jobs這種用新意折服世界的人，也要靠"現(xiàn)實(shí)扭曲力場(chǎng)"的幫助把自己的觀點(diǎn)有效地推行下去。

所以，這個(gè)方案雖然很不錯(cuò)，但是我不愿意繼續(xù)討論了，因?yàn)檫@在現(xiàn)實(shí)中沒有意義，脫離現(xiàn)實(shí)的例子也就不再是好例子了。

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

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

再一個(gè)方案

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

 
圖7 另一種解決方案

然后把Light類實(shí)現(xiàn)成這個(gè)樣子：（多酷啊，目前為止代碼量最少的方案）

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

代碼 4

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

設(shè)計(jì)思想（原則）及技術(shù)方案的濫用

每種設(shè)計(jì)都有他的思路和道理。你覺得不可理喻的設(shè)計(jì)可能恰恰是別人深思熟慮的結(jié)果，只是每個(gè)人的思路不一樣，結(jié)果自然也不相同。但是如果設(shè)計(jì)思路被某種設(shè)計(jì)思想占據(jù)了絕對(duì)主導(dǎo)的地位，就可能會(huì)出現(xiàn)設(shè)計(jì)上的偏差。

我把濫用大體上總結(jié)成如下三種：

1. 單純的濫用。因?yàn)槲視?huì)這么做，所以就順便這么做了。他們的理論基礎(chǔ)是：雖然現(xiàn)在沒有這要的需求，誰知道以后有沒有呢？我多做一點(diǎn)兒還不好？最典型的癥狀是，所有的類，都有相應(yīng)的接口，全部使用Dependency Injection來實(shí)例化。這不是有病么？

   這會(huì)引出一個(gè)比較大的話題，就是怎樣的設(shè)計(jì)算是過度設(shè)計(jì)？這需要單獨(dú)寫一節(jié)來討論這個(gè)問題。就不在這里展開了。

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

 
圖8. 因?yàn)槭煜せ驊卸瓒峤筮h(yuǎn)

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

#p#

一個(gè)真實(shí)的案例

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

為什么？一個(gè)可以賺到五個(gè)億的項(xiàng)目卻虧了幾個(gè)億？

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

那么效率為什么這么低？他們所有的業(yè)務(wù)邏輯都用PL-SQL實(shí)現(xiàn)，大的報(bào)表，涉及到的PL-SQL動(dòng)輒上萬行，而且層層調(diào)用，加之整個(gè)系統(tǒng)有數(shù)千個(gè)表。代碼的測(cè)試，都要先去數(shù)據(jù)庫造假數(shù)據(jù)。效率能高就怪了。

為什么要這么搞？因?yàn)橐婚_始做系統(tǒng)設(shè)計(jì)的人，對(duì)PL-SQL比較熟悉，對(duì)Java不熟悉，所以就把Java當(dāng)成了UI Wrapper來用。狗屎吧。當(dāng)然還會(huì)有很多其它的因素，但是在技術(shù)層面，這絕對(duì)是重要因素之一。因?yàn)樽约簩?duì)某個(gè)技術(shù)比較熟悉，而不愿意在項(xiàng)目中了解和應(yīng)用更適合的其它技術(shù)方案的人套上CTO之類的外衣，恒等于攪屎棍。

支持開關(guān)控制多個(gè)燈

簡單而言，要讓一個(gè)開關(guān)去控制所有的燈。聽上去很簡單，而且有很多種實(shí)現(xiàn)方式。但是如果仔細(xì)想想，會(huì)發(fā)現(xiàn)有很多問題。

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

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

需求分析的第一步，就是要對(duì)用戶的需求進(jìn)行分解、細(xì)節(jié)，找出合理用例。比如：用戶要求的是，要有統(tǒng)一開關(guān)，但是并沒有說每個(gè)燈就沒有自己的開關(guān)。如果每個(gè)燈又都有自己的開關(guān)，統(tǒng)一開關(guān)應(yīng)該如何與各個(gè)專屬開關(guān)協(xié)作呢？從這個(gè)角度，就可以找到一些用例。

1. 兩個(gè)燈，都開著。這時(shí)去按統(tǒng)一開關(guān)，應(yīng)該是全關(guān)對(duì)吧。也就是說，統(tǒng)一開關(guān)應(yīng)該知道當(dāng)前燈的狀態(tài)。并按當(dāng)前燈的狀態(tài)去執(zhí)行操作。
2. 三個(gè)燈，兩個(gè)開著。這時(shí)去按統(tǒng)一開關(guān)呢？統(tǒng)一開關(guān)的意思就是要有統(tǒng)一的行為，用戶肯定不會(huì)希望這個(gè)統(tǒng)一開關(guān)的行為是：把開著的燈關(guān)掉，把關(guān)著的燈打開。怎么辦？統(tǒng)計(jì)現(xiàn)在開著的比率？開著的多就全關(guān)？那如果是兩個(gè)燈，一個(gè)開著，一個(gè)關(guān)著呢？還有一個(gè)辦法是，讓統(tǒng)一開關(guān)使用代碼2的方案：自己記住上次的操作結(jié)果。上次是全關(guān)，這次就全開；反之亦然。

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

現(xiàn)實(shí)中的電路

現(xiàn)實(shí)中的電路圖有兩種做法。（非標(biāo)準(zhǔn)電路，請(qǐng)意會(huì)。強(qiáng)弱電相關(guān)專業(yè)也許可以參考這里）

 
圖9. 現(xiàn)實(shí)中的兩種簡單的總控加分支開關(guān)電路

前一張圖，分支開關(guān)有絕對(duì)的控制權(quán)；后一張圖中開關(guān)中有一個(gè)二極管，開關(guān)的開合用于控制二極管的極性，總開關(guān)的作用就是：把開著的關(guān)掉，把關(guān)著的打開。

看上去就是兩種開關(guān)嘛。

基于派生類的方案

為了讓一個(gè)開關(guān)可以控制多個(gè)燈，對(duì)現(xiàn)有程序設(shè)計(jì)上的改動(dòng)很小。類圖如下：

 
圖10. 多控開關(guān)設(shè)計(jì)

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

小結(jié)

本節(jié)本來是想講講需求決定設(shè)計(jì)這個(gè)理念，從兩個(gè)需求引出兩個(gè)互不兼容的設(shè)計(jì)方案。所以找了兩個(gè)需求一起講，但是最后這兩個(gè)需求并沒多大的沖突，也就沒有達(dá)到預(yù)期的目標(biāo)。不過想說的倒是說出來了。就是項(xiàng)目的設(shè)計(jì)，最終還是要依賴于需求，任何要做出能夠適應(yīng)未來需求的設(shè)計(jì)的想法，都是不切實(shí)際、勞民傷財(cái)?shù)?。（不知道有多少人?huì)把這句話曲解為"設(shè)計(jì)無用論"，如果我認(rèn)為設(shè)計(jì)無用，還會(huì)寫這個(gè)系列嗎？）

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

距上節(jié)的發(fā)布也已經(jīng)很久了，因?yàn)槊炕匕l(fā)表時(shí)，都會(huì)先想好下回寫什么、怎么寫，并結(jié)尾留個(gè)引子。這次很可惜，想好了下回寫什么，卻死活想不出合適的、簡單的需求來引出這個(gè)問題，也就不知道怎么寫了。所以下回什么能寫好我也不知道。大體上，也許還會(huì)有下而一些道理希望能和大家分享：

• 過度設(shè)計(jì)及關(guān)于"過度"的度量。
• 局部設(shè)計(jì)最優(yōu)化與全局次優(yōu)化之間的權(quán)衡。
• 什么是設(shè)計(jì)經(jīng)驗(yàn)及如何正確地借鑒。

新的用戶

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

• 在開關(guān)上加一個(gè)小燈，表示現(xiàn)在的燈是開還是關(guān)。（因?yàn)殚_關(guān)和燈可能并不在一起）
• 通過開關(guān)調(diào)節(jié)燈的亮度。
• 在開關(guān)上顯示燈的耗電量、溫度、預(yù)期壽命等。
• 定時(shí)開關(guān)。
• 開關(guān)聲控、手勢(shì)控。
• 開關(guān)權(quán)限控制。

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