偉大軟體的三步驟
1.確認你的軟體做客戶想要它做的事
2、運用基本的oo原則來增加軟體的靈活性---oo原則是什麼？
3、努力實現可維護、可重用的設計--什麼是可重用？
需求1.好的需求確保你的系統如預期那樣運作
2.確認你的需求涵蓋所有用例
3.運用用例找出客戶忘記的事
4.你的用例將揭露任何不完整遺漏的需求，你可能需新的需求加進你的系統中
5.你的需求總是隨著時間成長
分析與設計
1.設計良好的軟體容易改變與擴充套件
2.使用像封裝與繼承這樣的基本oo原則來確保你的軟體具有靈活性
3.如果設計沒有靈活性，就改變它！別與環設計拖鞋，幾時那是你自己的設計，要改就是要改。
4.確認你的每乙個類都具有內聚性：沒乙個雷都應該巨劍在把一件事情做得很好上。
內聚性：每個類確保這件事發生的理由只有乙個，類的改變不會一起其他類的改變
5.隨著軟體的設計生命週期的展開，要持續努力提高內聚力
oo原則
1.講變化之物封裝起來
2.對介面編碼，而不是對實現
3.應用程式的每乙個類只有乙個改變的理由。（內聚性）
4.類是關於行為與功能的
5.ocp(open-closed principle)開閉原則
對擴充套件開放，對修改關閉
擴充套件有效程式**，而不是改變當中的程式**
簡單的實現方式為繼承
6.（dry）do not repaeat yourself不自我重複原則
通過將共同之物抽取出來並置於單一地方來避免重複的程式**
確保你對應用程式中每乙個功能與需求只實現一次
特定片段與資訊具有單一**，該單一**必須合理
7.srp(single responsibility principle)單一職責原則
每乙個物件聚焦在乙個職責上
當你得每乙個物件都只有乙個改變的理由時，你已經正確地實現單一職責原則。
確保單一職責的方法
the 型別 方法名 itself 是否合理
8.lsp(liskov subsititution principle)替換原則
子型別必須能夠替換其基型別
lsp完全關係到設計良好的繼承。當你從乙個基類繼承下來時，你必須需能用你的子類替換該基類且不會把事情弄糟，
否則，你就錯誤地使用了繼承
繼承必須確保父型別所擁有的特質（屬性與方法），對子型別仍然成立(有意義)
假如發現程式**違反lsp，考慮利用委託,組合或聚合來使用來自其他類的行為而無需使用繼承
（子類不恩能夠替換它的基類時可能使用）
9.委託
委託是將特定工作的責任委派給另乙個類或方法
最好在你想要使用另乙個類的功能性時使用
假如你需要使用另乙個類的功能性，但不行改變該功能性，考慮以委託代替繼承
（子類不恩能夠替換它的基類時可能使用）
10.使用組合將來自其他多個類（）的行為集合起來
當引用一整群的行為時，使用組合
組合讓你使用來自一組其他類的行為，並且可以在執行時切換該行為
若物件有其他物件組成，當擁有物件被銷毀時，被擁有物件（組合的一部分）也跟著消失
在組合中，由其他行為所組成的物件用於那些行為。當物件被摧毀時，其所有行為也被摧毀。組合中的行為不存於組合本身以外。
11.聚合:組合，但沒有突然的結束
（子類不恩能夠替換它的基類時可能使用）
聚合時當乙個類被用作另乙個類的一部分時，但仍然可以存在於該類之外
12.除了繼承，有幾種方式可以重用來自其他類的行為
委託:當你不想改變其行為，而實現該行為不是此物件本身的責任時，就將行為委託給另乙個類
組合：使用組合，你可以重用來自乙個或多個類的行為，特別是來自乙個族群的類的行為。你得主要物件完全用於被組合物件
，而且被組合物件不存在主要物件之外
聚合：當你想要組合的所有好處，但是也想要在主要物件之外使用被組合物件的行為時，就使用聚合
假如你喜歡委託、組合、聚合勝過繼承，你的軟體通常會更靈活，更易維護，擴充套件與重用。
解決大問題
1.收集功能列表
2.設計用例圖，必須涵蓋系統的功能列表
參與者：與系統互動的部分，不總是系統的使用者
3.領域分析：用客戶所用的語言檢查你得設計
4.為系統設計模組，將大問題分解成小的功能片段
5.運用設計模式幫助我們解決小的問題
架構定義：架構是你的設計結構，強調應用程式中最重要的部件以及那些部件之間的關係
從功能入手，找出最重要的功能，可能由多個組成
架構三問：
1.他是系統本質的一部分嗎？（你能想象系統沒有這個功能嗎？）
2.這到底是什麼意思？假如你部確定某項功能的敘述究竟是什麼意思，把注意力放在改功能上可能就很重要
3.我「到底"該如何做？假如你不知道如何處理某特定問題，最好花點時間去正視該功能
從哪個最重要的功能開始？關鍵是減少風險
架構拼圖與構建場景
開發方式:
1.用例驅動開發
2.功能驅動開發
3.測試驅動開發
程式設計實踐
1.契約式程式設計為你與軟體使用者同意遵守的軟體行為建立乙個共同的協議
2.防禦性程式設計不信任其他軟體，進行廣泛的錯誤及資料檢查以確保其他軟體不會給你不良的或不安全的資訊
物件導向分析設計專案的生命週期
1.功能列表:從高層次找出應用程式應該做什麼
客戶訪談
關鍵功能列表
2.用例圖：確認應用程式要執行的大流程，以及任何牽涉到的外部力量
外部啟動器
3.分解問題：將應用程式分解成功能性模組，接著決定以什麼樣的次序處理每個模組
架構分析
共同性委託
變化性4.需求：為每個功能模組想出各自的需求，並且確定他們復合整體輪廓
外部啟動器
場景替換路徑
迭代需求列表
5.領域分析：想出你的用例如何對應到應用程式理的物件，確認你課客戶跟你又相同的認識
文字分析
6.初步設計：加入關於物件的細節，定義物件之間的關係，並且運用原則與設計模式
封裝設計模式
設計原則
類圖迭代
7.實現：編寫程式**，進行測試，確認它有效運作。為每個行為，每個功能，每個用例，每個問題，做這些事，直達你完成.
oo原則
封裝測試驅動
功能驅動
用例驅動
測試場景
8.交付
物件導向分析
物件導向分析 1 物件導向分析，就是抽取和整理使用者需求並建立問題域精確模型的過程。首先，系統分析員對需求文件進行分析 然後是需求建模 最後是需求評審。2 物件導向分析要建立三個主要模型 用例模型 物件模型 和動態模型。建立用例模型 在物件導向方法中為了獲取使用者需求常常用場景和用例描述使用者需求。...
物件導向分析
一 分析方法之功能分解 functional decomposition 原理 將問題或功能分解成多個小問題或小功能，然後逐一解決 缺點 a.導致讓乙個 主 程式負責控制程式，主程式的責任太多 可使用委託delegation解決 同時，引 起另外乙個問題，低內聚weak cohesion 緊耦合ti...
C 物件導向分析
物件導向分析屬於軟體開發過程中的問題定義階段，其目標是清晰 精確地定義問題領域。傳統的系統分析產生一組面向過程的文件，定義目標系統的功能 物件導向分析則產生一種描述系統功能和問題領域的基本特徵的綜合文件。原則物件導向分析的主要原則如下。1.抽象 從許多事物中捨棄個別的 非本質的特徵，抽取共同的 本質...