☆☆☆☆☆
簡體網頁||繁體網頁



點擊這裡下載

類似圖書 點擊查看全場最低價

---

編輯推薦

　　1. 介紹麵嚮對象設計方法中的架構和設計模式。 　　2. 有助於提高軟件的編寫質量，加深對軟件理論知識的理解，擴展專業視野，瞭解大型軟件開發中的架構模式。 　　3. 介紹的設計模式和架構模式都配有Java語言的程序實例，模式中類和類之間的靜態關係或對象間的動態關係都用UML語言描述。各章末均提供瞭相應的練習。 　　4. 本書在網絡上提供各章練習答案和書中實例的Java代碼。 　　5. 可以作為高校計算機相關專業的教材，也可供係統開發人員和大型係統的係統架構設計人員閱讀參考。

內容簡介

　　《世界著名計算機教材精選：軟件架構與模式》可供計算機專業學生、工科學者、係統開發人員和大型係統的係統架構設計人員閱讀。本書的目標是讓讀者掌握係統架構和模式的基本原理與實際應用。

內頁插圖

目錄

第1章 麵嚮對象設計的原理 1
1.1 程序的可讀性、正確性和
可擴展性 2
1.1.1 可讀性 2
1.1.2 正確性 2
1.1.3 可擴展性 3
1.2 封裝、抽象和信息隱藏 3
1.3 關注點分離和單一職責
原則 4
1.4 接口隔離原則 6
1.5 鬆耦閤 6
1.6 裏氏代換原則 7
1.7 契約式設計 9
1.7.1 斷言 9
1.7.2 覆寫要遵守契約 11
1.8 開閉原則 13
1.9 依賴倒置原則和控製反轉 18
1.9.1 依賴倒置原則 18
1.9.2 控製反轉 19
1.10 對象生成過程中減少
?依賴性 21
?1.10.1 依賴查找 22
?1.10.2 依賴注入 26
1.11 總結 28
1.12 練習 29
第2章 軟件架構 30
2.1 軟件架構概念 31
2.2 軟件架構的質量 32
2.3 參考架構、架構模式和設計
模式 33
2.4 軟件架構概念的任務和前景 34
2.4.1 係統中的分析任務 34
2.4.2 係統中的結構設計
任務 35
2.4.3 觀察軟件架構的
角度 37
2.4.4 軟件架構的原型 37
2.5 軟件架構師對一個項目的
意義 37
2.5.1 軟件架構師的技術
能力 38
2.5.2 軟件架構師的溝通
能力 38
2.5.3 構造軟件架構過程中
的決定 39
2.6 總結 40
2.7 練習 41
第3章 軟件設計的模式 42
3.1 模式的使用 43
3.2 模式的屬性和它的設計 44
3.3 架構模式、設計模式和慣用
法的界限 44
3.4 描述設計模式和架構模式的
模闆 46
3.5 總結 47
3.6 練習 47
第4章 麵嚮對象設計模式 48
4.1 設計模式的分類 48
4.2 設計模式的概述 49
4.2.1 結構模式 49
4.2.2 行為模式 50
4.2.3 創建型模式 51
4.2.4 設計模式指南 51
4.3 結構模式中的適配器模式 51
4.3.1 名稱/其他可用的
名稱 51
4.3.2 問題 51
4.3.3 解決方法 52
4.3.4 評價 57
4.3.5 使用範圍 58
4.3.6 類似的模式 58
4.4 結構模式中的橋梁模式 58
4.4.1 名稱/其他可用的
名稱 58
4.4.2 問題 58
4.4.3 解決方法 59
4.4.4 評價 66
4.4.5 使用範圍 67
4.4.6 類似的模式 67
4.5 結構模式中的裝飾模式 67
4.5.1 名稱/其他可用的
名稱 67
4.5.2 問題 67
4.5.3 解決方法 68
4.5.4 評價 76
4.5.5 使用範圍 77
4.5.6 類似的模式 80
4.6 結構模式中的外觀模式 81
4.6.1 名稱/其他可用的
名稱 81
4.6.2 問題 81
4.6.3 解決方法 81
4.6.4 評價 86
4.6.5 使用範圍 86
4.6.6 類似的模式 86
4.7 結構模式中的組閤模式 87
4.7.1 名稱/其他可用的
名稱 87
4.7.2 問題 87
4.7.3 解決方法 87
4.7.4 評價 95
4.7.5 使用範圍 95
4.7.6 類似的模型 97
4.8 結構模式中的代理模式 97
4.8.1 名稱/其他可用的
名稱 97
4.8.2 問題 98
4.8.3 解決方法 98
4.8.4 評價 102
4.8.5 使用範圍 102
4.8.6 類似的模式 103
4.9 行為模式中的模闆方法
模式 104
4.9.1 名稱/其他可用的
名稱 104
4.9.2 問題 104
4.9.3 解決方法 104
4.9.4 使用範圍 108
4.9.5 評價 109
4.9.6 類似的模式 109
4.10 行為模式中的命令模式 109
4.10.1 名稱/其他可用的
?名稱 109
4.10.2 問題 109
4.10.3 解決方法 110
4.10.4 評價 115
4.10.5 使用範圍 116
4.10.6 類似的模式 116
4.11 行為模式中的觀察者模式 117
4.11.1 名稱/其他可用的
?名稱 117
4.11.2 問題 117
4.11.3 解決方法 117
4.11.4 評價 124
4.11.5 使用範圍 124
4.11.6 類似的模式 125
4.12 行為模式中的策略模式 125
4.12.1 名稱/其他可用的
??名稱 125
4.12.2 問題 125
4.12.3 解決方法 125
4.12.4 使用範圍 129
4.12.5 評價 129
4.12.6 類似的模式 130
4.13 行為模式中的中間者
?模式 130
4.13.1 名稱/其他可用的
??名稱 130
4.13.2 問題 131
4.13.3 解決方法 131
4.13.4 評價 138
4.13.5 使用範圍 138
4.13.6 類似的模式 138
4.14 行為模式中的狀態模式 139
4.14.1 名稱/其他可用的
??名稱 139
4.14.2 問題 139
4.14.3 解決方法 139
4.14.4 使用範圍 146
4.14.5 評價 146
4.14.6 類似的模式 146
4.15 行為模式中的角色模式 147
4.15.1 名稱/其他可用的
??名稱 147
4.15.2 問題 147
4.15.3 解決方法 148
4.15.4 評價 155
4.15.5 使用範圍 155
4.15.6 類似的模式 156
4.16 行為模式中的拜訪者模式 156
4.16.1 名稱/其他可用的
??名稱 156
4.16.2 問題 156
4.16.3 解決方法 156
4.16.4 評價 169
4.16.5 使用範圍 170
4.16.6 類似的模式 171
4.17 行為模式中的迭代器模式 171
4.17.1 名稱/其他可用的
??名稱 171
4.17.2 問題 171
4.17.3 解決方法 171
4.17.4 評價 178
4.17.5 使用範圍 178
4.17.6 類似的模式 180
4.18 創建型模式中的工廠
??方法 180
4.18.1 名稱/其他可用的
??名稱 180
4.18.2 問題 180
4.18.3 解決方法 181
4.18.4 評價 185
4.18.5 使用範圍 185
4.18.6 類似的模式 186
4.19 創建型模式中的抽象工廠
??模式 186
4.19.1 名稱/其他可用的
??名稱 186
4.19.2 問題 186
4.19.3 解決方法 186
4.19.4 評價 195
4.19.5 使用範圍 195
4.19.6 類似的模式 196
4.20 創建型模式中的單例模式 196
4.20.1 名稱/其他可用的
??名稱 196
4.20.2 問題 196
4.20.3 解決方法 196
4.20.4 評價 204
4.20.5 使用範圍 204
4.20.6 類似的模式 204
4.21 創建型模式中的對象池
??模式 204
4.21.1 名稱/其他可用的
??名稱 204
4.21.2 問題 205
4.21.3 解決方法 205
4.21.4 評價 210
4.21.5 使用範圍 211
4.21.6 類似的模式 211
4.22 總結 211
4.23 練習 213
第5章 架構模式 216
5.1 分層架構模式 217
5.1.1 名稱/其他可用的
名稱 217
5.1.2 問題 217
5.1.3 解決方法 217
5.1.4 評價 219
5.1.5 使用範圍 220
5.1.6 類似的模式 226
5.2 管道和過濾器架構模式 226
5.2.1 名稱/其他可用的
名稱 226
5.2.2 問題 226
5.2.3 解決方法 227
5.2.4 評價 232
5.2.5 使用範圍 232
5.2.6 類似的模式 234
5.3 插件架構模式 235
5.4 中介模式 245
5.5 麵嚮服務的架構模式 267
5.6 模型-視圖-控製器架構模式 291
5.7 總結 307
5.8 練習 308
參考文獻 310
　　
　　

精彩書摘

　　第3章 軟件設計的模式

　　軟件開發過程中的每一步都有對應的模式：用於係統分析的模式、係統設計模式、編程模式和測試模式。對於特殊的任務也有模式，比如對設計圖形界麵或者與數據庫的數據交換。

　　本書專注於軟件設計中的模式。這裏要注意它們的區彆：

　　* 架構模式（architectural patterns）。

　　* 設計模式（design patterns）。

　　確定架構模式和設計模式的界限參見3.3節。

　　用於設計的模式是已經經過證實的可用於解決一些特定問題的參考答案。在設計係統時要考慮使用模式，因為它們都是已經在多個係統中被證明過的。

　　設計階段的模式起源於架構師Christopher Alexander1。他在20世紀70年代整理總結瞭一套城市建設的模式。Christopher Alexander認識到，建築或者整條街道雖然可能包括相同的元素，但是完全可以按照不同的模式建造。換句話說，他通過元素和它們之間典型的關係可以辨彆模式。

　　“……除瞭元素之外，每個建築都是由元素之間的關係組成的一定模式定義的……” [Ale77]

　　在城市建築學中，模式是一個具有開創性意義的理念。但是它在建築學中的流行和認可的程度遠遠不如在軟件開發領域。

　　模式對係統設計起到瞭重要的貢獻，它促使軟件開發在走嚮成熟的工程技術的道路上邁齣瞭重要的一步。模式基本上是不依靠任何平颱，不被限製於一種固定的編程語言。被命名的模式擴展瞭專業技術語言，受過訓練的開發人員可以在一個更高的抽象層次中理解一個問題和答案。

　　模式經常要和抽象結閤，它是一個抽象類或者接口的符號。真實的類是派生類，模式並不知道派生類，它們是由使用模式的用戶定義的。它們或者在編譯時齣現在以具體類為基礎的模式中，或者是在運行時在麵嚮對象模式中替代模式中的抽象 部分。

　　為瞭使模式可以供其他開發者使用，必須做好文檔工作。模式不是發明齣來的，而是在實際應用中因為可以解決典型的問題而被發現齣來的方法，它們可以在很多實際應用中使用。

　　3.1節研究在軟件設計中模式的使用。3.2節描述在軟件設計中模式的屬性和它的設計。3.3節確定架構模式、設計模式和慣用法相互的界限。在3.4節中介紹模闆，本書中利用這個模闆介紹如何給模式做文檔。

　　3.1 模式的使用

　　軟件設計中模式的主要目標是通過再次使用已經獲得的經驗提高架構的靈 活性。

　　大部分係統設計中包含很多模式，僅僅通過這個特徵還不能判斷這是一個好的設計。

　　這裏Christopher Alexander使用瞭適當的語言：“建築可能是通過鬆散排列的模式建造的。這樣的建築隻能體現齣模式的聚集，並不具有內部的一緻性，它沒有真正的核心。還有一種模式結閤的方式就是在同一空間的多模式疊加。這樣的建築具有內部的一緻性，它把很多的含義包含在一個小的空間裏。通過這種內部的凝聚力使它具有核心力。”一個好的設計的形成，需要多個模式相互間完美地組閤，形成疊加效應。

　　隻有在真正有意義的時候纔可以使用模式。在使用模式之前，一定要仔細考慮要使用的模式是否適閤解決這個問題，使用之後會産生什麼樣的結果。

　　從開發者的角度認為模式具有一定的安全性。這種安全性是建立在事實的基礎上的，是前人經過應用已經得到證實的結果。然而這容易形成誤導，認為在任何情況下使用模式都是正確的選擇。單純使用模式並不能保證對於設計中齣現的具體問題是有意義的。

　　在以對象為基礎的模式中委托原則經常起到重要的作用。委托一個用於接收信息的對象，消息可以繼續傳遞給

　　* 接收信息的對象所聚集的部分對象；

　　* 或者是在運行時實現一個抽象（接口或抽象類）的對象（這個抽象是由接收信息的對象實現的）。

　　使用任何形式的委托或者抽象，其代價都是降低係統的性能。額外增加的層次總是和降低係統的性能相聯係的。

　　如果要求係統具有擴展性，那麼模式的使用具有優勢。但是如果首先是對係統性能的要求，係統的可修改性沒有重要作用時，使用模式就要仔細考慮。

　　盡管使用模式可以提高架構的可擴展性，但是同時也增加瞭架構的復雜度。

　　為瞭保證可擴展性，可能會生成新的類和操作，或者是新的類和類之間的關係。這種復雜度會降低係統的性能，在這種情況下，復雜度所帶來的優點並不能抵消性能降低的不足。

　　如果係統需要靈活性是推測的，即目前還不清楚係統將來是否需要，那麼就應該“隻保持必要的靈活性，越少越好”。

　　本書關於模式的介紹，其核心是解釋如何解決問題。然而，這個問題的實質是什麼時候適閤使用模式。這個問題往往被忽視瞭。也許沒有已知的模式可以達到預期的目標。

　　尋找解決具體設計問題的方法是艱難的，人們必須仔細研究待解決的問題，比較有關模式的性能。

　　3.2 模式的屬性和它的設計

　　模式的目標就是提高架構的屬性。例如屬性包括下麵兩點：

　　* 可理解性；

　　* 可擴展性。

　　可理解性可以通過簡易性達到，即通過為每個模式提供簡易的結構化的全麵文檔。可擴展性可以通過以下兩點實現：

　　* 靜態繼承。

　　* 使用聚閤接口2或者是抽象類。

　　麵嚮對象模式滿足以下設計原則：

　　* 鬆耦閤性係統（詳見1.5節），組件的鬆耦閤性。

　　* 抽象（詳見1.2節），通過泛化、接口或者抽象類。

　　* 信息隱藏（詳見1.2節），通過隱藏程序實現的部分。

　　* 明確的職責（詳見1.3節），通過角色安排。

　　* 依賴倒置原則，高層的類不依賴於低層的類。

　　這裏需要強調的是有時候需要為非麵嚮對象係統製定模式。這樣的模式不需要繼承和多態[Bus98，24頁]。模式不一定都是麵嚮對象的。本書中所介紹的設計模式都是以麵嚮對象為基礎的。

　　人們想到麵嚮對象時，總會認為是通過泛化達到盡可能高的抽象，換句話說，就是找到它的基類，通過細分得到不同的變化。

　　因此一些模式就設計成以抽象類為基類，還有一些模式使用接口。人們更偏愛於使用接口，有兩個原因：

　　（1）在一些編程語言中，例如Java，接口允許多重繼承，抽象基類則不允許。

　　（2）抽象基類可以包含抽象操作，也可以包含已經完成的操作。接口則隻能包含抽象操作，這樣更讓人一目瞭然。

　　接口優於抽象類，但這並不總是成立的。如果人們在每個實現類中都必須實現一個聚集或者默認實現，這種情況就應該使用抽象類。

　　3.3 架構模式、設計模式和慣用法的界限。

　　……

前言/序言

　　譯 者 序

　　隨著中德兩國交往的不斷加深，各行各業都在不斷地拓展多方位的閤作。但是中德兩國在軟件行業的閤作卻並不多見，來自德國的計算機類翻譯著作也非常少。

　　德國企業齣於嚴謹的風格和安全性的考慮，基本很少有軟件外包，對於應用軟件的開發和使用一般也都局限在德國本土範圍內（除瞭一些大型公司，如SAP），所以我們對德國計算機行業的發展瞭解得並不多。

　　本書的作者Goll教授不僅有多年的計算機軟件 世界著名計算機教材精選：軟件架構與模式 下載 mobi epub pdf txt 電子書

評分☆☆☆☆☆

一些經典的思想和案例

評分☆☆☆☆☆

書是正版，質量沒問題。送貨速度快，還在看。

評分☆☆☆☆☆

好評！

評分☆☆☆☆☆

頭腦一熱買瞭，還沒好好看，愛，收藏吧

評分☆☆☆☆☆

頭腦一熱買瞭，還沒好好看，愛，收藏吧

評分☆☆☆☆☆

對於想提高編程水平，很有參考價值

評分☆☆☆☆☆

好書，值得推薦。

評分☆☆☆☆☆

此用戶未填寫評價內容

評分☆☆☆☆☆

對於想提高編程水平，很有參考價值

類似圖書 點擊查看全場最低價