1、拙劣設計的症狀：
這些症狀在本質上和**的臭味相似，但是它們所處的層位稍高一些。
2、物件導向設計的solid原則。
3、臭味和原則。
設計中的臭味是一種症狀，是可以主觀進行度量的（但很難客觀進行度量）。這些臭味常常是由於違反了這些原則中的乙個或者多個而導致的。敏捷團隊應用這些原則去除臭味。當沒有臭味時，他們不會應用這些原則。僅僅因為是乙個原則就無條件的去遵循它的做法是錯誤的。這些原則不是可以隨意在系統中到處噴灑的香水。過分遵循這些原則會導致不必要的複雜性的設計臭味。
4、軟體專案的設計是乙個抽象的概念。uml圖，設計文件都只是描述設計的一些部分。最終的設計體現為源**。
5、在大多數軟體專案中最不穩定的東西就是需求。需求處在乙個持續變動的狀態之中。這是我們作為開發人員必須得接受的事實！
6、敏捷開發人員面對需求變更時，應該抓住變更的機會去改進設計，並使修改後的設計對於同一類需求問題的變化具有彈性，而不是設法去給設計打補丁。
注意：這時的「打補丁」做法也許能使一時的修改快速完成，但是它不是簡單設計。它不符合開閉原則。打上補丁後的設計已經出現了某種設計臭味。
7、敏捷開發人員如何知道要做什麼？
軟體開發的這三個方面間的作用就是設計。
8、敏捷設計是乙個過程，不是乙個事件。它是乙個持續的應用原則、模式以及實踐來改進軟體的結構和可讀性的過程。
9、單一職責原則（srp）：高內聚性（cohesion）。
10、開放-封閉原則（ocp）：如果遵循ocp原則，那麼一旦對乙個變化做出改進設計以後，再對同樣的變化改動時，就只需要新增新的**，而不必改動已經正常執行的**。對擴充套件開放也就是說增加新功能只需要編寫新**；對修改封閉也就是說增加新功能不需要修改原有**。
11、實現ocp原則的關鍵是抽象。策略模式/模板方法模式/狀態模式
12、當然，一般而言，無論模組是多麼的「封閉」， 都會存在一些無法對之封閉的變化。沒有對於所有的情況都是貼切的模型。既然不可能完全封閉，那麼就必須有策略地對待這個問題。
因此，設計人員必須對於他設計的模組應該對哪種變化封閉做出選擇。他必須猜測出最有可能發生變化的種類，然後構造抽象來隔離哪些變化。這需要設計人員具備一些從經驗中獲得的**能力。
但是，這一點不容易做到。如果開發人員猜測正確，他們就獲得成功；如果他們猜測錯誤，他們就會遭受失敗。並且在大多數情況下，他們都會猜測錯誤。
那麼，我們如何知道哪乙個變化有可能發生呢？我們進行適當的調查，提出正確的問題，並且使用我們的經驗和一般常識。最終，我們會一直等到變化發生時才採取行動。變化一旦來臨，我們抓住機會改進設計，並使得修改後的設計對同類變化保持彈性，符合ocp。
13、介面屬於客戶。clientinte***ce（而不是serverinte***ce）說明抽象類和它們的客戶的關係要比和實現它們的子類的關係更密切一些。
14、封裝變化，**變化就封裝**。我們一開始不需要也沒有必要去猜測變化。但是，變化一旦出現，我們必須抓住機會改進設計，使修改後的設計能夠對同一類變化封閉。因此，抽象是關鍵，抽象是最穩定的東西。
15、開放-封閉原則（ocp）是物件導向設計的核心所在。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處（也就是，靈活性、可重用性和可維護性）。ocp背後的主要機制是抽象（abstraction）和多型（polymorphism）。而支援抽象和多型的關鍵機制之一是繼承（inheritance）。在使用繼承時有乙個重要的原則需要注意，那就是黎克特制替換原則（lsp）。
16、liskov替換原則（lsp）：若對每個型別s的物件o1，都存在乙個型別t的物件o2，使得在所有針對t編寫的程式p中，用o1替換o2後，程式p的行為功能不變，則s是t的子型別。
17、對於黎克特制替換原則的違反也常常會導致對開閉原則的違反，從而使**中出現使用執行時型別辨別（rtti）。這種方式難免使得客戶端**出現switch或if/else語句。
18、如果乙個新派生型別的建立會導致我們去修改它的基類，這就常常意味著設計是有缺陷的（當然也違反了ocp）。
19、有效性並非本質屬性。
由黎克特制替換原則可以得出乙個重要的結論：乙個模型，如果孤立的看，並不具有真正意義上的有效性。模型的有效性只能通過它的客戶程式來表現。
20、is-a關係是針對行為的。lsp清楚的指出，ood中is-a關係是就行為方式而言的，行為方式是可以進行合理假設的，是客戶程式所依賴的。
21、基於契約設計（design by contact）：在重新宣告派生類的例程時，只能使用相等的或更弱的前置條件來替換原始的前置條件；只能使用相等或者更強的後置條件來替換原始的後置條件。
22、在大多數情況下，接受乙個多型中的微秒錯誤都不會比試著修改設計使之完全符合lsp更為有利。接受缺陷而不是去追求完美這是乙個工程上的權衡問題。好的工程師知道何時接受缺陷比追求完美更為有利。不過，不應該輕易放棄對於lsp原則的遵循。
23、用提取公共部分的方法代替（直接的）繼承。例如，類line和類linesegment， 線和線段具有許多的相同屬性，但是它們在行為上不是嚴格的is-a關係。linesegment繼承自line會帶來問題，例如線一定有截距；但線段可能沒有截距。更好的做法是通過提取乙個linearobject物件作為line和linesegment的抽象基類，可以很好的塑造上合理的模型。——這是乙個ood的重要工具。
24、違反黎克特制替換原則的典型跡象：
在派生類中存在退化函式並不總是表示違反了lsp，但是當存在這種情況時，還是值得注意一下的。
25、ocp是ood中很多說法的核心。而lsp使ocp成為可能。
26、依賴倒置原則（dip）： 高層模組不應該依賴於低層模組，二者都應該依賴於抽象；抽象不應該依賴於細節，細節應該依賴於抽象。
這樣做的目的是：低層模組的改動不至於影響高層模組；細節的改動不會影響到抽象。只有抽象介面層的改動才會促使高層模組和細節做出相應的改動，然而，抽象通常都是比較穩定的。因此，這是一種合理的設計。依賴倒置原則（dip）是框架（framework）設計的核心原則。
27、倒置的介面所有權。（不要呼叫我們，我們會呼叫你）
依賴倒置原則中的「倒置」不僅僅是依賴關係的倒置，它也是介面所有權的倒置。在應用依賴倒置原則（dip）時，我們發現往往是客戶擁有抽象介面，而它們的服務者則從這些抽象介面中派生。
28、依賴於抽象。有個啟發式規則：
當然，任何程式都有違反該規則的情況。但是這些規則值得我們注意。
29、介面隔離原則（isp）用來處理「胖」介面所具有的缺點。那麼什麼是「胖」介面？如果類的介面不是內聚的，就說明這個類的介面是『胖「的。我們通常說，要使介面盡量的」窄「，就是這樣道理。
30、胖類會導致它們的客戶程式之間產生不正常的並且有害的耦合關係。當乙個客戶程式要求該胖類進行乙個改動時，會影響到所有其它的客戶程式。因此，客戶程式應該僅僅依賴於它們實踐呼叫的方法。介面卡模型可以幫助我們很好的分離介面，解決胖類介面的困擾，防止介面汙染。
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早並...
敏捷軟體開發讀書筆記 敏捷軟體開發宣言及其原則
原文 the agile alliance its principles 根據個人理解翻譯，僅供參考 敏捷軟體開發宣言 個體與交流 勝過過程和工具 可用的軟體 勝過面面俱到 的文件 客戶協作 勝過合同談判 響應變化 勝過遵循計畫 上列各條中，右側雖然也有價值，但左側的價值更大。敏捷宣言原則 1.盡早...
敏捷軟體開發
敏捷軟體開發 英語 agile software development 又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟體開發方法，是一種應對快速變化的需求的一種軟體開發能力。它們的具體名稱 理念 過程 術語都不盡相同，相對於 非敏捷 更強調程式設計師團隊與業務專家之間的緊密協作...