《深入淺出面向對象分析與設計（中文版）》一書的出版社是東南大學出版社，作者是麥克勞克林(Mclaughlin,B.D)。
基本介紹
圖書簡介,目錄,
圖書簡介
你是否早已對市面上那些只有在成為專家以後讀起來才有感覺的OOA&D書籍感到厭倦？你可能早就聽說過OOA&D書籍能幫助你寫出偉大的軟體——讓老闆高興、客戶滿意的軟體。
但如何辦到呢？
《深入淺出面向對象分析與設計》將告訴你如何分析、設計以及撰寫真正面向對象的軟體：容易重用、好維護、可擴展的軟體；不再使你心碎的軟體；讓你增添新功能而不會破壞舊機制的軟體。在本書中，你將學到：使用諸如封裝(encapsulation)與委派(delegation)之類的OO原則建立靈活的應用程式；使用開閉原則(Open-Closed Principle)與單一職責原則(Single-Responsibilitv Principle)提升程式的重用性；學習如何將OO原則、設計模式及各種開發方法通通整合到OOA&D項目的生命周期里；運用UML、用例及用例圖來確保所有利害關係人都能清楚地進行溝通，協助你交付正確的軟體，達到每個人的要求。
目錄
介紹
誰適合讀這本書？
我們知道你在想什麼
元認知
讓你的腦袋順從你的方法
讀我
技術審閱團隊
致謝
1 偉大軟體由此開始：良好應用程式的基石
永遠的搖滾樂！
Rick的金光閃閃的新應用程式
什麼是你要改變的第一件事？
偉大軟體……
偉大軟體的簡易三步驟
先聚焦在功能性上
測試驅動
尋找問題
分析
運用基礎的OO原則
設計一次，設計兩次
改變你的應用程式有多簡單？
封裝變化之物
委託
最後的偉大軟體(就現在而言)
OOA&D關係到編寫偉大軟體
要點
2 給客戶所需之物：收集需求
大顯身手的機會來了
測試驅動
不正確的使用(有一點)
那么，需求究竟是什麼？
創建需求列表
為錯誤作規劃
替代路徑(alternate path)處理系統的疑：
(再次)介紹用例
一個用例，三個部分
按照用例檢查需求
你的系統必須在真實世界裡運作
認識快樂路徑(Happy Path)
OOA&D工具箱
3 山可移，此情永不渝……現在，情況有變：需求變更
你是英雄！
犧牲品？
軟體分析與設計的不變真理
可選路徑？替換路徑？誰能分得清？
用例對你而言必須合理
從開始到完成：單一場景
替換路徑的真心話
完成需求列表
重複程式代碼，遜！
最後的測試驅動
寫下你自己的設計原則
OOA&D工具箱
4 將你的軟體帶進現實世界：分析
一隻狗，兩隻狗，三隻狗，四隻狗……
你的軟體有其情境
識別問題
規劃解法方案
兩位程式設計師的故事
委託繞道
低耦合應用程式的威力
注意用例里的名詞
從好分析到好類……
類圖解析
類圖不是一切
要點
5 第一部分：諸行無常——良好的設計
Rick的吉他事業蒸蒸日上
抽象類
類圖解析(再一次)
UML小抄
設計問題的警告
通往偉大軟體的三步驟(重訪)
插曲：OO大災難
5 第二部分：給你的軟體30分鐘的伸展操——靈活的軟體
回到Rick的搜尋工具
仔細瞧瞧search()方法
分析的好處
類實際上關係到行為
設計之死(決策)
將壞的設計決策轉變成好的
Rick的軟體中的“雙封裝”
不要害怕犯錯及改變
瞧！Rick的具有靈活性的應用程式
測試驅動Rick的設計良好的軟體
改變Rick的軟體有多容易？
變更容易性的大挑戰
具有內聚性的類善於處理好單一事情
設計/內聚力生命周期
偉大的軟體通常就是“夠好的軟體”
OOA&D工具箱
6 “我的名字是Art Vandelay”：解決真正的大問題
解決大問題
關鍵在於你如何看待大問題
需求與用例是個好起點……
共同性與變化性
整理功能
功能與需求之間的“差別”
用例不總是幫你看出整體輪廓
用例圖
小小參與者
參與者也是人(好吧，不全然)
做一點領域分析吧
化整為零，個個擊破
別忘了真正的客戶是誰
何謂設計模式？
OO&D的威力(以及一些小常識)
OOA&D工具箱
7 為混亂帶來次序：架構
感覺有點頭昏嗎？
我們需要架構
從功能開始
什麼是架構的意義？
架構三問
減少風險
場景有助於減少風險
一次把焦點放在一個功能上
架構是你的設計結構
再訪共同性
共同性分析：通往靈活軟體之路
什麼意思？問客戶吧。
減少風險有助於偉大軟體自
要點
8 原創性被高估：設計原則
設計原則大集合
開關原則(OCP)
OCP，一步一步來
不自我重複原則(DRY)
DRY完全關係到一個地方一個需求
單一職責原則(SRP)
找出多重職責
從多重職責到單一職責
Liskov替換原則(LSP)
子類化的誤用：誤用繼承的案例研究
LSP揭露繼承結構所隱藏的問題
子類型必須能替換其基類型
違反LSP造成令人困惑的程式代碼
將功能性委託給其他類
使用組合將來自其他多個類的行為集合起來
聚合：組合，但沒有突然的結束
組合VS．聚合
繼承只是選項之一
要點
OOA&D工具箱
9 軟體終究為客戶服務：重複與測試
你的工具箱滿了
偉大軟體的編寫是疊代進行的
更深入地疊代：兩種基本選擇
功能驅動開發
用例驅動開發
兩種開發方式
功能分析
編寫測試場景
測試驅動開發
再探共同性
強調共同性
強調封裝
比對你的測試與設計
測試案例解析……
向客戶證明
到目前為止，我們一直在按契約編程
按契約編程關乎信任
防禦性編程
將你的應用程式分解成較小的功能塊
要點
OOA&D工具箱
10 組合在一起：OOA&D生命周期
開發軟體，OOA&D風格
對象村旅遊
對象村捷運線路圖
功能列表
用例反映使用性，功能反映功能性
現在開始疊代
仔細看看捷運的表示
使用或不使用Line類……那是個問題
對象村捷運的關注要點(Subway類)
保護你的類(還有客戶的類)
中場休息
回歸需求階段……
聚焦於程式代碼，然後聚焦於客戶
疊代(iteration)讓問題比較容易
路線看起來像什麼？
讓自己看看對象村！
第三次疊代，有人要試試嗎？
旅程未結束……
附錄1：本書遺珠
附錄2：歡迎光臨對象村
誰適合讀這本書？
我們知道你在想什麼
元認知
讓你的腦袋順從你的方法
讀我
技術審閱團隊
致謝
1 偉大軟體由此開始：良好應用程式的基石
永遠的搖滾樂！
Rick的金光閃閃的新應用程式
什麼是你要改變的第一件事？
偉大軟體……
偉大軟體的簡易三步驟
先聚焦在功能性上
測試驅動
尋找問題
分析
運用基礎的OO原則
設計一次，設計兩次
改變你的應用程式有多簡單？
封裝變化之物
委託
最後的偉大軟體(就現在而言)
OOA&D關係到編寫偉大軟體
要點
2 給客戶所需之物：收集需求
大顯身手的機會來了
測試驅動
不正確的使用(有一點)
那么，需求究竟是什麼？
創建需求列表
為錯誤作規劃
替代路徑(alternate path)處理系統的疑：
(再次)介紹用例
一個用例，三個部分
按照用例檢查需求
你的系統必須在真實世界裡運作
認識快樂路徑(Happy Path)
OOA&D工具箱
3 山可移，此情永不渝……現在，情況有變：需求變更
你是英雄！
犧牲品？
軟體分析與設計的不變真理
可選路徑？替換路徑？誰能分得清？
用例對你而言必須合理
從開始到完成：單一場景
替換路徑的真心話
完成需求列表
重複程式代碼，遜！
最後的測試驅動
寫下你自己的設計原則
OOA&D工具箱
4 將你的軟體帶進現實世界：分析
一隻狗，兩隻狗，三隻狗，四隻狗……
你的軟體有其情境
識別問題
規劃解法方案
兩位程式設計師的故事
委託繞道
低耦合應用程式的威力
注意用例里的名詞
從好分析到好類……
類圖解析
類圖不是一切
要點
5 第一部分：諸行無常——良好的設計
Rick的吉他事業蒸蒸日上
抽象類
類圖解析(再一次)
UML小抄
設計問題的警告
通往偉大軟體的三步驟(重訪)
插曲：OO大災難
5 第二部分：給你的軟體30分鐘的伸展操——靈活的軟體
回到Rick的搜尋工具
仔細瞧瞧search()方法
分析的好處
類實際上關係到行為
設計之死(決策)
將壞的設計決策轉變成好的
Rick的軟體中的“雙封裝”
不要害怕犯錯及改變
瞧！Rick的具有靈活性的應用程式
測試驅動Rick的設計良好的軟體
改變Rick的軟體有多容易？
變更容易性的大挑戰
具有內聚性的類善於處理好單一事情
設計/內聚力生命周期
偉大的軟體通常就是“夠好的軟體”
OOA&D工具箱
6 “我的名字是Art Vandelay”：解決真正的大問題
解決大問題
關鍵在於你如何看待大問題
需求與用例是個好起點……
共同性與變化性
整理功能
功能與需求之間的“差別”
用例不總是幫你看出整體輪廓
用例圖
小小參與者
參與者也是人(好吧，不全然)
做一點領域分析吧
化整為零，個個擊破
別忘了真正的客戶是誰
何謂設計模式？
OO&D的威力(以及一些小常識)
OOA&D工具箱
7 為混亂帶來次序：架構
感覺有點頭昏嗎？
我們需要架構
從功能開始
什麼是架構的意義？
架構三問
減少風險
場景有助於減少風險
一次把焦點放在一個功能上
架構是你的設計結構
再訪共同性
共同性分析：通往靈活軟體之路
什麼意思？問客戶吧。
減少風險有助於偉大軟體自
要點
8 原創性被高估：設計原則
設計原則大集合
開關原則(OCP)
OCP，一步一步來
不自我重複原則(DRY)
DRY完全關係到一個地方一個需求
單一職責原則(SRP)
找出多重職責
從多重職責到單一職責
Liskov替換原則(LSP)
子類化的誤用：誤用繼承的案例研究
LSP揭露繼承結構所隱藏的問題
子類型必須能替換其基類型
違反LSP造成令人困惑的程式代碼
將功能性委託給其他類
使用組合將來自其他多個類的行為集合起來
聚合：組合，但沒有突然的結束
組合VS．聚合
繼承只是選項之一
要點
OOA&D工具箱
9 軟體終究為客戶服務：重複與測試
你的工具箱滿了
偉大軟體的編寫是疊代進行的
更深入地疊代：兩種基本選擇
功能驅動開發
用例驅動開發
兩種開發方式
功能分析
編寫測試場景
測試驅動開發
再探共同性
強調共同性
強調封裝
比對你的測試與設計
測試案例解析……
向客戶證明
到目前為止，我們一直在按契約編程
按契約編程關乎信任
防禦性編程
將你的應用程式分解成較小的功能塊
要點
OOA&D工具箱
10 組合在一起：OOA&D生命周期
開發軟體，OOA&D風格
對象村旅遊
對象村捷運線路圖
功能列表
用例反映使用性，功能反映功能性
現在開始疊代
仔細看看捷運的表示
使用或不使用Line類……那是個問題
對象村捷運的關注要點(Subway類)
保護你的類(還有客戶的類)
中場休息
回歸需求階段……
聚焦於程式代碼，然後聚焦於客戶
疊代(iteration)讓問題比較容易
路線看起來像什麼？
讓自己看看對象村！
第三次疊代，有人要試試嗎？
旅程未結束……
附錄1：本書遺珠
附錄2：歡迎光臨對象村
