敏捷軟體開發原則,模式與實踐書摘

2021-06-16 08:00:15 字數 1182 閱讀 3280

敏捷軟體開發原則,模式與實踐書摘。

拙劣設計的症狀:

物件導向設計原則:

例子1:圖示

liskov替換原則(the liskov subsitution principle, 簡稱lsp)

例子1: 圖示1

例子1:圖示2

程式示例:

template

void persistentset::add(const t& t)

例子1:圖示3

例子1:依賴倒置可以應用於任何存在乙個類向另乙個類傳送訊息的地方。例如,button物件和lamp物件之間的情形。button物件感知外部環境的變化。但接收到poll訊息時,它會判斷是否被使用者「按下」。它不關心是通過什麼樣的機制去感知的。可能是gui上的按鈕圖示,也可能是乙個能夠用手指按下的真正按鈕,甚至可能是乙個家庭安全系統中的運動檢測器。button物件可以檢測到使用者啟用或關閉它。

lamp物件會影響外部環境。當接收到turnon訊息時,它顯示某種燈光。當接收到turnoff訊息時,它把燈光熄滅。它可以是計算機控制台的led,也可以是停車場的水銀燈,甚至是雷射印表機中的雷射。

該如何設計乙個用button物件控制lamp物件的系統呢?下圖1展示了乙個不成熟的設計。button物件接收poll訊息,判斷按鈕是否被按下,接著簡單地傳送turnon或者turnoff訊息給lamp物件。這個模型的相應**如下**段1所示。請注意button類直接依賴於lamp類。這個依賴意味著,當lamp類改變時,button類會受到影響。此外,想要重用button來控制乙個motor物件是不可能的。在這個設計中,button物件控制著lamp物件,並且也只能控制lamp物件。這個方案違反了dip。應用程式的高層策略沒有和底層實現分離。抽象沒有和具體細節分離。沒有這種分離,高層策略就自動地依賴於底層模組,抽象就會自動地依賴於具體細節。

介面隔離原則(the inte***ce segregation principle, 簡稱isp)

不應該強迫客戶依賴於它們不用的方法

(胖介面)。

如果強迫客戶程式依賴於那些它們不使用的方法,那麼這些客戶程式就面臨著由於這些未使用方法的改變所帶來的變更。這無意中導致了所有客戶程式之間的耦合。換種說法,如果乙個客戶程式依賴於乙個包含它不使用的方法的類,但是其它客戶程式卻要使用這些方法,那麼當其它客戶要求這個類改變時,就會影響到這個客戶程式。應該盡可能避免這種耦合,因此需要分離介面(拆分為多個具有內聚介面的抽象基類)。

敏捷軟體開發(原則,模式與實踐)

教堂尖頂上的風標,即使由鋼鐵製成,如果不懂得順應風勢的藝術,一樣會被風暴立即摧毀。海因里希.海涅 一 敏捷軟體開發宣言 1 個體和互動勝過過程和工具 人是獲得成功的最為重要的因素。合作 溝通以及互動能力要比單純的程式設計能力更為重要。乙個由平均水平程式設計師組成的團隊,如果具有良好的溝通能力,將比那...

敏捷軟體開發 原則 模式與實踐 之敏捷實踐

參與公司的敏捷開發也有一段時間了,還沒有系統的學習過敏捷開發。比如早上的站會,每個月的迭代會,還有自己領取任務去開發故事,這些都是敏捷開發的流程之一。敏捷開發需要不斷的學習,不斷的實踐。現在開始寫一些關於敏捷開發的部落格。一 敏捷聯盟 1 個體和互動勝過過程和工具 乙個優秀的團隊成員未必是乙個一流的...

敏捷軟體開發 原則 模式與實踐 (一)

為了達到敏捷開發,我們需要使用一些實踐提供必要的準則和反饋,需要使用一些設計原則使我們的軟體保持靈活且可維護,還需要理解一些已經被證明在特定問題中可以權衡這些原則的設計模式。敏捷軟體開發宣言 人和互動 重於 過程和工具 可以工作的軟體 重於 面面俱到的文件 客戶合作 重於 合同談判 隨時應對變化 重...