1.1.4 局限性
設(shè)計模式并非銀彈。您必須充分理解首要解決的問題,將其泛化,然后運(yùn)用某個適合它的模式。但是,并非所有問題都需要設(shè)計模式。設(shè)計模式確實(shí)能夠幫助人們將復(fù)雜的問題變得簡單,但是同樣也能夠讓本來簡單的問題變得復(fù)雜。
在閱讀有關(guān)模式的書籍之后,許多開發(fā)者都掉進(jìn)了一個陷阱:試圖把設(shè)計模式運(yùn)用到所做的每件事情,但最終取得的效果卻與設(shè)計模式初衷(也就是讓事情變得簡單)相反。前面曾經(jīng)說過,運(yùn)用模式的較好方法是,通過識別正在試圖解決的基本問題,來尋找適合它的解決方案。本書將幫助您識別什么時候以及如何使用設(shè)計模式,繼而從ASP.NET的角度來討論如何實(shí)現(xiàn)。
并非總要使用設(shè)計模式。如果您已經(jīng)為某個問題找到一種簡單(但又不是過于簡陋的)、清晰而且可維護(hù)的解決方案,那么倘若該方案并不屬于GoF(四人組)設(shè)計模式中的某一個模式,也不要責(zé)備自己。否則,就會讓自己的設(shè)計過于復(fù)雜。
這段有關(guān)設(shè)計模式的討論此時給人的感覺可能相當(dāng)模糊,但是在繼續(xù)閱讀本書的過程中,您將學(xué)習(xí)每個設(shè)計模式打算解決的問題類型,并了解如何在ASP.NET中實(shí)現(xiàn)這些設(shè)計模式,然后就能夠?qū)⑦@些模式運(yùn)用到自己的應(yīng)用程序中。
1.2 設(shè)計原則
設(shè)計原則構(gòu)成了設(shè)計模式賴以構(gòu)建的基礎(chǔ)。它們要比設(shè)計模式更加基礎(chǔ)。通過遵循經(jīng)過驗(yàn)證的設(shè)計原則,自己的代碼基會變得更加靈活、更能夠適應(yīng)變化,而且可維護(hù)性更佳。下面將簡要地介紹一些比較著名的設(shè)計原則以及一組被稱為S.O.L.I.D.原則的原則。在本書后面將更為深入地了解這些原則,然后在ASP.NET中實(shí)現(xiàn)它們及最佳實(shí)踐。
1.2.1 常見設(shè)計原則
如同設(shè)計模式一樣,有一些常見的設(shè)計原則歷經(jīng)多年已經(jīng)變成了最佳實(shí)踐,并構(gòu)成了企業(yè)級軟件和可維護(hù)軟件可以賴以構(gòu)建的基礎(chǔ)。下面將預(yù)覽一些廣為人知的原則。
1. 簡約原則(KISS)
軟件編程領(lǐng)域普遍存在的一個問題是需要把解決方案過度復(fù)雜化。KISS原則的目標(biāo)就是讓代碼保持簡潔但不要過于簡陋,從而避免引入任何不必要的復(fù)雜度。
2. 不要重復(fù)自已(DRY)
DRY原則的目的是通過將公用的部分抽離出來放在一個單獨(dú)的地方從而避免重復(fù)系統(tǒng)中的任何部分。這個原則不僅涉及代碼而且包括系統(tǒng)中重復(fù)的任何邏輯。最終,系統(tǒng)中的任何一部分知識都應(yīng)該只有一種表示形式。
3. 講述而不要詢問(Tell, Don't Ask)
“講述而不要詢問”原則體現(xiàn)了封裝以及將責(zé)任指派到正確的類這兩個思想。這個原則要求,應(yīng)該告訴對象您希望它們執(zhí)行什么動作,而不是詢問有關(guān)該對象狀態(tài)的問題然后由您自己決定希望執(zhí)行什么動作。這個原則有助于匹配責(zé)任并避免類之間的緊密耦合。
4. 您不需要它(YAGNI)
YAGNI原則指的是只需要將應(yīng)用程序必需的功能包含進(jìn)來,而不要試圖添加任何其他您認(rèn)為可能需要的功能。測試驅(qū)動開發(fā)(TDD)就是一種堅持YAGNI原則的設(shè)計方法學(xué)。TDD的宗旨就是編寫測試來驗(yàn)證系統(tǒng)的功能,然后只需要編寫可讓測試通過的代碼即可。本章稍后部分將討論TDD。
5. 分離關(guān)注點(diǎn)(SoC)
SoC這一過程將軟件分解為多項(xiàng)不同的功能,每項(xiàng)功能封裝了可供其他類使用的唯一行為和數(shù)據(jù)。通常,一個關(guān)注點(diǎn)代表類的一項(xiàng)功能或行為。將程序劃分成若干獨(dú)立職責(zé)的做法顯著提高了代碼的重用程度、維護(hù)性和可測試性。
在本書剩余部分將追溯這些設(shè)計原則,這樣您就能夠了解它們是如何實(shí)現(xiàn)的,以及如何幫助建立干凈的、可維護(hù)的面向?qū)ο笙到y(tǒng)。下面將要看到的是S.O.L.I.D.設(shè)計原則分類中收集的設(shè)計原則。