ASP.NET MVC論壇應用程序(上)
我想通過本系列文章從頭到尾構建一個完整的ASP.NET MVC論壇應用程序，最終的目的是探討和推動使用ASP.NET MVC框架構建應用程序的最佳實踐。
1、 簡介
在本篇中，我想先從全局方面介紹一下論壇應用程序的總體目標。在本篇中，我將討論一下避免代碼壞味道的重要性，還將討論如何利用軟件設計原則和模式來幫助你編寫適合未來改變的富有彈性的代碼。最后，我還將論證一下為什么我選擇使用測試驅動開發方式構建本系列文章中的論壇應用程序。
2、 什么樣的軟件是好的軟件
我不想僅僅為了構建論壇應用程序而任意構建此論壇應用程序。我的目標是盡可能構建最棒的論壇應用程序。
這個目標立即引發這樣一個問題：什么樣的軟件是好的軟件？是什么導致一個應用程序比另一個應用程序更好一些或更差一些呢？在事先沒有一個關于“好軟件”的定義之前，我無法聲明我構建了一個完美的論壇應用程序。
因此，下面是我對于“好軟件”的定義。
3、 好軟件是設計得易于修改的軟件
存在多種原因可能需要你改變軟件：
1)你可能需要在一個現有軟件上添加新的特征
2)你可能需要修改一個現有軟件中的錯誤
3)你可能需要優化現有軟件
4)你可能需要改進現有軟件的設計
一般說來，設計糟糕的軟件是難于改變的。有些軟件設計得如此糟糕，以致于每個人都害怕碰一碰它。我們大家應該都使用過設計得糟糕的軟件。當軟件不好時，你很希望它干脆走開；甚至如果有機會的話，你可能想從頭開始重新編寫這款軟件。
4、 避免代碼壞味道
Robert和Micah Martin把糟糕的軟件部分描述為代碼壞味道。下列代碼壞味道意味著此軟件的書寫是相當糟糕的：
1)僵化性（Rigidity）—僵化的軟件是這樣的軟件，當你在某個位置作一改動時即要求對系統作出相應的一系列的更改。
2)脆弱性（Fragility）—脆弱的軟件是這樣的軟件，你在某個位置作一改動時即打斷另外多處的正常運行。
3)不必要的復雜性—不必要的復雜軟件是指過度設計的軟件，其目的是為了處理任何可能的改變。
4)不必要的重復—不必要的重復軟件中包含大量的重復性代碼。
5)晦澀性—晦澀的軟件是指難于理解的軟件。
【注意】上述這些代碼味道在Micah和Robert Martin的著名《Agile Principles,Patterns,and Practices in C#》中得到充分的描述。在此，強烈建議讀者讀一下這本書。
注意，上述這些代碼味道都與所有的代碼改變相關聯。每一個這些代碼味道都將妨礙代碼的改變。
5、 軟件設計原則
遵循良好的軟件設計原則，將有助于編寫軟件易于適應未來更改的軟件。軟件設計原則有若干，也不盡相同。例如，Cunningham和Cunningham Wiki描述面向對象設計的11個原則：
http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign。
其中提到的面向對象設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles,Patterns,and Practices in C#》中所主張的軟件設計原則是一致的。此外，Robert Martin還在Object Mentor開辟的博客上討論了這些原則：
http://www.objectmentor.com/resources/publishedArticles.html。
此外，我還發現有另外兩本書中也提供了有關軟件設計原則的極其有用的信息。第一本是Eric Freeman,Elisabeth Freeman, Kathy Sierra, Bert Bates編著的《Head First Design Patterns》；第二本是Brett McLaughlin,Gary Pollice和David West編著的《Head First Object-Oriented Analysis and Design》。盡管這些書所討論的原則與Robert Martin的提法并不十分相同，但是它們卻十分相近。
不過真實的情況是，上述所有這些針對軟件設計原則展開討論的資源都源自Robert Martin的工作。Robert Martin并不是所有原則的發明者，但是他的確是第一個把這些原則收集到一起的人。下面列出這些軟件設計原則：
◆SRP—單一責任原則
◆OCP—開關原則
◆LSP—Liskov替換原則
◆ISP—接口隔離原則
◆DIP—依賴倒置原則
上述這個原則的集合正好對應于縮略詞SOLID。
下面的軟件設計原則列表來自于《Head First Design Patterns》一書：
◆封裝變化
◆多用組合少用繼承
◆基于接口而不是基于實現編程
◆在交互的對象間努力實現松耦合
◆類應該為了擴展而開放，但是為了修改而關閉
◆依賴于抽象，而不要依賴于具體類
◆僅僅對你的朋友交談
◆不調用我，我們會調用你
◆一個類應該僅有一個改變的理由
當然，上述原則之間也存在許多的重疊之處。例如，“單一責任”原則與后面的“一個類應該僅有一個改變的理由”這一原則是相一致的。然而，它們所強調的重點還是有所不同。更多的細節在此不便贅述。
所有這些設計原則的真正動機在于，努力構建出能夠適應變化的軟件。上述原則分別對于不同的原則進行相應的闡述，最終目的也不過是為了創建出可以經得起時間測試的軟件。
【編輯推薦】
