敏捷軟件開發 之第二部分 敏捷設計

3月箴言

人的思想是了不得的，只要專一於某一項事業，就必定會作出使本身感到吃驚的成績來。—— 馬克·吐溫

開啓第二部分：敏捷設計

1、拙劣設計的症狀：

致使這些症狀出現的緣由：

一、最最最主要的緣由就是代碼界的段子：CV戰士（我想大多數的代碼搬運工是能夠明白的，哈哈哈）

二、不斷變化的需求（這個是沒法避免的，需求一個持續變更的事實）

敏捷設計：是一個過程，而不是一個事件！它是一個持續的應用原則、模式以及實踐來改變軟件的結構和可讀性的過程。它致力於保持系統設計在任什麼時候候都儘量的簡單、乾淨以及富有變現力。

我的理解就是：接受變化，學習使用軟件設計原則、模式，讓程序健壯、易懂！（畢竟看代碼的不是機器）

2、部分面向對象設計原則

3、單一職責原則（SRP）：就一個類而言，應該僅有一個引發它變化的緣由。

若是一個類有多個引發它變化的緣由，那麼這個類就具備多個職責。

若是一個緣由會引發幾個職責同時變化，這種狀況下不在拆分這幾個職責；若是一個緣由僅引發一個職責變化，另外一個職責依賴於其餘緣由變化，這種狀況須要將這兩個職責分離以知足SRP原則。

關於示例，在以後的編寫過程當中完善再在本次文章中添加！

4、開放-封閉原則（OCP）：軟件實體（類、模塊、函數等）應該是能夠擴展的，可是不能夠修改的。

一、「對於擴展是開放的」：模塊的行爲能夠擴展，也就是能夠改變模塊的功能。

二、「對於更改是封裝的」：對模塊的行爲擴展時，沒必要改動模塊的源代碼或者二進制代碼。

這一原則的關鍵是抽象。

模塊能夠操做一個抽象體，因爲模塊依賴於一個固定的抽象類，因此對於它的更改能夠是關閉的，同時，經過這個抽象體派生，也能夠擴展此模塊的行爲。

根據文中的示例我的理解是：

一、對於某一模塊，建立一個抽象類（我我的理解爲基類），包含基礎屬性和方法等；

二、具體的狀況，建立該基類的一種子類，子類中覆寫基類的屬性、方法以知足該子類狀況的實現；

三、若是新增了一種基類實現，就建立一個新的該基類的子類，用於擴展該模塊，而不須要修改基類。

關於抽象的具體作法：當程序中出現頻繁變化的那些部分作出抽象！

---------------------------我是分割線- ------------------------------------------------

---------------------------2019.3.23- ------------------------------------------------

---------------------------我是分割線- ------------------------------------------------

 5、Liskoc替換原則（LSP）：子類型（subtype）必須可以替換他們的基類型（base type）。

 對於這一原則理解的具體實現示例：OC語言中KVO的實現模式！當一個Obj註冊addObserver方法的時候，在運行時會建立繼承於obj的子類，在子類的setter方法中實現具體的其餘實現，從而實現kvo的總體邏輯。

注意點：

一、有效性並不是本質屬性：一個模型，若是孤立地看，並不具備真正意義上的有效性。模型的有效性只能經過它的客戶程序來表現；

二、IS-A是關於行爲的：LSP清楚的指出，OOD中IS-A關係是就行爲方式而言的，行爲方式是能夠進行合理假設的，是客戶程序所依賴的；

三、基於契約設計：契約是經過爲每一個方法聲明前置條件和後置條件來制定的。要使一個方法得以執行，前置條件必須爲真。執行完畢以後，該方法的要保證後置條件爲真。

關於子類、基類：

在從新聲明派生類的例程（routine）時，只能使用相等或者更弱的前置條件的前置條件來替換原始的前置條件，只能使用相等或者更強的後置條件來替換原始的後置條件。

也就是說，當經過基類的接口使用對象時，用戶只知道基類的前置條件和後置條件。所以，派生類對象不能指望這些用戶聽從比基類更強的前置條件，同時派生類必須和基類全部後置條件同樣。

（弱：若是X沒有聽從Y的全部約束，那麼X就比Y弱，X所聽從的新的約束的樹木時可有可無的）

四、在單元測試中指定契約。

本原則關鍵字：「可替換性」。

6、依賴倒置原則（DIP）：高層模塊不該該依賴於底層模塊，兩者都應該依賴於抽象；抽象不該該依賴於細節，細節應該依賴於抽象。

（對於本原則的理解尚有疑惑）

依賴於抽象：

一、任何變量都不該該持有一個指向具體類的指針或者引用

二、任何類都不該該從具體類派生

三、任何方法都不該該覆寫它的任何基類中已經實現了的方法

我的理解：

通常狀況下

ManagerObj  處理一個按鈕的打開/關閉 操做

ButtonObj： open/close 

依賴倒置的下的處理方式：

一個抽象的類 BtnObj，BtnObj類聲明 open/close方法

ManagerObj 依賴於BtnObj

ButtonObj 繼承自BtnObj，ButtonObj內部是open/close的具體實現

7、接口隔離原則（ISP）：不該該強迫客戶依賴於他們不用的方法。

這個原則基於OC語言能夠理解爲代理，具體的能夠參考系統關於UITableViewDelegate 和 UITableViewDataSourece的實現

 

目前關於原則的先到這裏，這些原則仍是要多理解，在實戰中按部就班的使用 

 

PS：軟件開發原則、模式學習實踐之路任重道遠，難難難，嘆嘆嘆！