無心中在百度百科查看單一職責原則的介紹,提到面向對象五大設計原則(SOLID)是在《敏捷軟件開發:原則、模式與實踐》提出的。 我很是推崇這些設計原則,以爲這是軟件設計中很是偉大的思想。竟然沒有讀過這本神做,趕快讀起來。程序員
做者又叫Bob大叔,編程界的巨匠,我很是喜歡他的《代碼整潔之道》。沒想到代碼整潔之道還不算他最具含金量的圖書,還有不少對編程界影響深遠的圖書。《敏捷軟件開發:原則、模式與實踐》就是其中一本。數據庫
從書名能夠看出,本書一共是四塊內容編程
敏捷開發是針對團隊而言的。是在說團隊怎麼怎麼樣。因此理解敏捷開發,要拉大咱們的視角,從團隊的視角考慮開發。設計模式
書中的話語,要結合歷史語境來寫,做者所在的年頭,項目組應該都很重視工具,流程。應該也是當時的大公司,大項目吧。可是做者認爲,項目組內應該以人爲本,重視的素質,重視人和人的溝通。函數
若是不合理使用工具,那再好的工具也白扯,若是流程很是複雜,那也會影響團隊的效率。工具
大而笨重的過程會下降團隊的開發效率。書中並無解釋大而笨重的過程是什麼。我猜測就是開發大型項目有着複雜的瀑布模型的流程吧。單元測試
一種新的價值觀的產生,一個團隊應該怎樣開發軟件,才能更好的開發軟件。測試
一批專家提出了敏捷開發宣言:設計
咱們仍是要結合歷史來理解這四點,我理解當時的開發環境和如今仍是有所不一樣的。如今開發多以產品爲主,持續交付和產品迭代已成爲常態,產品經理提一個小需求,開發,而後上線。而在當時,多以項目爲主,開發某某大型系統。都是針對一個大型客戶,爲其定製一款軟件。因此瀑布模型是瓜熟蒂落的。把需求全提出來,而後再設計軟件,編寫代碼。面向對象設計模式
但瀑布模型真正實踐起來,就很麻煩,須要不少的過程和工具,因此專家們說,要讓團隊內的程序員多多溝通,而不是走各類過程。
文檔太多很麻煩,仍是要讓代碼足夠清晰,而且能夠工做。文檔只描述關鍵的事。軟件能夠工做在如今看來是再正常不過的事,不過若是按照瀑布流的模式開發,幾個月只寫系統的一個模塊(好比數據庫操做模塊這種),那幾個月客戶都看不到成型的系統,要等到全部模塊都開發完。而敏捷開發推崇持續的交付,讓客戶針對一個需求點,能看到完整的功能。
客戶合做賽過合同談判,相應變化賽過遵循計劃,也是由於軟件一般都很複雜,客戶最開始的描述每每也不許確,讓開發團隊閉門形成顯然不合理。
有了上面的價值觀,書中就提出些更具體的,在開發過程當中,團隊應該怎麼作。 好比隨時擁抱變化,業務人員和開發人員每天一塊兒工做。
這些原則並非必定要遵守纔對,而是一種思路,咱們要找到適合本身團隊的原則。
開發團隊的目標,就是給客戶交付最大可能的價值。敏捷開發能更好的實現咱們的目標。
又有個概念須要咱們理解了,啥是極限編程。 極限編程就是敏捷開發的一組具體的實踐。好比結對編程,重構這樣的東西。
描述了極限編程團隊中對於計劃的規劃。讓項目是小步迭代和發佈的。
編寫單元測試,解釋測試驅動開發。這是一種開發方式,也會影響咱們的思惟方式。編寫出的代碼也更加的解構。
重構能夠說是保持代碼質量的重要環節。天天清潔咱們的代碼。
做者以一次實踐來解釋上面所闡述的概念。
在這一部分,做者提出了偉大的面向對象五大設計原則。 並提出了什麼樣的設計是拙劣的,也就是違背設計原則的。
源代碼就是設計,不須要過多的媒介去描述它。
敏捷設計是一個持續的過程,不是一個事件。持續應用原則、模式改進軟件結構和可讀性。致力於任什麼時候間都儘量的簡潔有力。
就一個類而言,應該僅有一個引發它變化的緣由。
軟件實體(類、模塊、函數等等)應該是能夠擴展的,可是不可修改的。
子類型必須可以替換掉他們的基類型。
a. 高層模塊不該該依賴於底層模塊。兩者都應該依賴於抽象。 b. 抽象不該該依賴於細節。細節應該依賴於抽象。
不該該強迫客戶依賴於他們不用的方法。
接下來還有四章,都是以實際案例,來實踐敏捷開發和設計原則。而且提出相應的設計模式。
推薦你們閱讀這本經典圖書。編寫出更加優美的程序。