課程簡介
1、全真案例，借助案例與設計模式知識的原理，借助最佳實踐，幫助您提高設計能力，從而提高開發(fā)效率和設計質(zhì)量
2、以新視角，揭示模式的本質(zhì)、思想方法，剖析出模式之“道”，跳出“為模式而模式”的“陷阱”
3、提升設計能力，使開發(fā)人員由“編程小工”到設計專家
4、結合測試驅(qū)動開發(fā)與重構，提高軟件設計質(zhì)量
5、關注業(yè)界內(nèi)設計模式，以實戰(zhàn)訓練驅(qū)動對設計模式的理解與運用
目標收益
培訓對象
1、員工無法接手遺留系統(tǒng)，原因是代碼雜亂，可讀性差
2、團隊成員沒有設計模式知識與經(jīng)驗，無法實施敏捷開發(fā)
3、系統(tǒng)難以重構，不利于產(chǎn)品的重用與二次開發(fā)
4、開發(fā)效率得不到保障，因為詳細設計人員不能理解架構文檔與詳細設計方案
5、設計方案難于應對需求變更
6、設計的系統(tǒng)架構缺乏可擴展性、可維護性和可測試性，不能合理地重用
7、架構、設計、開發(fā)三個環(huán)節(jié)中各個角色不能理解設計意圖，很難溝通
課程大綱
|
議題一：卓越的軟件設計思想 卓越軟件設計的特征 |
? 體現(xiàn)簡單之美的設計方案 ? 可重用的對象與組件 ? 支持良好的可擴展性 ? 充分的測試覆蓋率 ? 可讀性高的代碼； |
| 案例分析 |
? 代碼閱讀：通過運用組合方法模式思想對代碼進行重構，進而演化為Template Method模式去除重復代碼 ? 代碼閱讀：分析面向?qū)ο笤O計方法所不能解決的重復問題，從而引入函數(shù)式思想去除重復 ? 郵件服務器：分析郵件服務器代碼暴露的問題，在可重用性、代碼可維護性、可擴展性等諸多方面著手，剖析代碼壞味道。 |
| 面向?qū)ο蟮脑O計要素 |
? 合理封裝的要點 ? 迪米特法則 ? 繼承與委派的區(qū)別 ? 關注點分離原則 ? 多態(tài)與抽象 |
| 案例分析 |
? 報表系統(tǒng)之參數(shù)處理：了解封裝的本質(zhì)，明確職責的分配以及智能對象的意義，理解“信息專家”模式。 ? 事務處理的設計：通過分析職責的承擔者，從而辨別職責的分配，并以組合橋接的方式進行抽象的分離。 ? 電子商務系統(tǒng)之訂單處理：對行為的封裝，職責的委派而非繼承的方式，進而重構到Command模式。 |
| 面向?qū)ο笤O計核心的SOLID原則 |
? 單一職責原則（SRP）：該原則是合理封裝對象，分配職責的重要原則； ? 開放封閉原則（OCP）：該原則體現(xiàn)了擴展式開發(fā)的核心思想； ? Liskov替換原則（LSP）：可以將該原則視為是對是否正確運用繼承的檢驗標準； ? 接口隔離原則（ISP)：對于接口的粒度進行規(guī)劃，以便于設計出更好的接口； ? 依賴倒置原則（DCP）：對于依賴和解耦的分析，利用抽象保證設計的可擴展性； |
|
議題二：整潔代碼與重構 編寫整潔的代碼 |
? 糟糕的代碼與混亂的代價，整潔代碼的藝術； ? 如何對變量、方法和類進行命名； ? 如何設計方法，遵循DRY與CQS原則； ? 如何進行錯誤處理和異常處理； ? 如何組織類和包； |
| 案例分析 | 給出真實項目中真實的代碼片段，對這些代碼進行分析，并利用整潔代碼的原則進行改善。這些代碼涉及到的問題包括：循環(huán)嵌套太多，方法命名不合理，缺乏足夠的封裝，性能問題； |
| 通過重構改善既有代碼 |
? 破窗理論與重構的原則，包括重構與設計的關系，重構的時機和開展重構的原因 ? 介紹代碼的壞味道：詳細介紹各種代碼的壞味道，包括重復的代碼、過長函數(shù)、過大類、依戀情結、平行繼承體系、發(fā)散式變化、霰彈式修改等22種壞味道。 ? 介紹常見的重構手法，例如提取參數(shù)、提取方法、提取類、搬移方法、提取參數(shù)對象，以委托取代繼承等，并利用實際的案例展現(xiàn)如何對丑陋的代碼進行重構。 |
| 案例分析 | 對媒體管理系統(tǒng)的壞味道識別，利用重構改善代碼，并逐步引入Strategy模式與Visitor模式，進而改善設計。 |
|
議題三：合理的職責分配是良好設計的基礎 職責驅(qū)動設計 |
? 職責的層次：包括職責層次的識別、職責層次與軟件架構層次之間的關系、職責與概念、規(guī)約與實現(xiàn) ? 對象的角色：角色、職責與協(xié)作是三位一體的關系，角色是發(fā)起職責的對象，職責則應該是對象之間的協(xié)作 ? 模塊級的職責分配：如何根據(jù)職責對模塊進行分解，了解高內(nèi)聚、松耦合原則。 |
| 案例分析 |
? 對郵件服務器進行分析，通過分辨職責層次，來改善設計。并提出需求變更，從而引入對觀察者模式、策略模式、簡單工廠模式、調(diào)停者模式與職責鏈模式的對比與分析； ? 處理HTTP請求與應答，體現(xiàn)信息持有者角色； ? JMS對Queue的創(chuàng)建體現(xiàn)構造者角色； ? 稅務報告的生成體現(xiàn)服務提供者角色； ? 服務定位器體現(xiàn)協(xié)調(diào)者角色； ? 內(nèi)容驗證器體現(xiàn)控制者角色； ? EISaaS的模塊劃分； ? 基于AKKA的REST框架Spray； ? 國際報稅系統(tǒng)的架構演進，提出模塊重用的方式； |
| 職責分配遵循的原則與模式 |
? 分析單一職責原則：分析該原則的核心思想，關注對象的變化點 ? 專家模式：專家模式的核心思想是信息的持有者是操作該信息的專家 ? 自治對象：分析了自治對象的特征，分別包括：最小完備，穩(wěn)定空間，自我履行與獨立進化 |
| 案例分析 | ? 設備狀態(tài)的遷移：利用“自治對象”思想逐步引入State模式，并結合實際需求分析標準State模式的問題，從而對該模式進行改進 |
|
議題四：應對需求的變化，設計可擴展的軟件 如何應對需求的變化 |
? 抽象的關鍵在于尋找多個對象（或行為）具有的共同特征，并對特性進行泛化 ? 函數(shù)式非凡的抽象能力 ? 識別變化點，對變化進行封裝 ? 解耦具體依賴：介紹常見的解除具體依賴的方法，包括表驅(qū)動法、配置與反射、IoC容器、慣例優(yōu)于配置 案例分析 ? 項目管理模型的抽象，通過對多種項目管理過程進行分析，對各種模型概念進行分類，并抽象出模型的共同特征，從而簡化模型； ? 電子商務系統(tǒng)的票據(jù)業(yè)務規(guī)則，引入Specification模式； ? CIMS系統(tǒng)的機器加載策略，引入Strategy模式； ? 短信服務，引入Facade模式與Adpater模式； ? 人力資源系統(tǒng)考勤模塊，介紹Gateway模式； ? URL Web請求，講解如何解耦具體依賴； |
| 擴展式設計 | ? 擴展式設計的過程 |
| 案例分析 |
? 消息隊列規(guī)范的設計：通過分析JMS、MSMQ的設計，理解抽象的含義，例如理解面向接口設計、接口隔離原則、按意圖設計、Facade模式； ? 保單問卷調(diào)查：講解如何從壞設計逐步重構到Visitor模式； |
|
議題五：設計模式的本質(zhì) 設計模式的境界 |
? 初學者：拔劍四顧心茫然，不知道該如何運用設計模式 ? 熟練者：過尤不及，為模式而模式，常常導致設計過度 ? 精通者：無招勝有招，掌握了設計模式的本質(zhì)，能夠恰如其分地運用設計模式 |
| 設計的常見問題 |
? 理論與設計無法有效結合 ? 過度運用設計模式 ? 急于編碼，沒有有效的設計 |
| 設計模式的本質(zhì) |
? 合理的職責分配是基礎 ? 封裝并抽象變化是核心 ? 合理運用面向?qū)ο笤O計思想 ? 合理運用面向?qū)ο笤O計原則 |
| 案例分析：JUnit框架 |
通過全面剖析JUnit測試框架，了解大師的設計藝術，展現(xiàn)JUnit是如何保證框架的簡單、可擴展、可重用。內(nèi)容包括： ? JUnit的組件結構 ? JUnit的Test Case設計 ? 如何支持Test Result顯示的擴展 ? JUnit中如何通過復雜的設計來簡化用戶的使用 |
|
議題一：卓越的軟件設計思想 卓越軟件設計的特征 ? 體現(xiàn)簡單之美的設計方案 ? 可重用的對象與組件 ? 支持良好的可擴展性 ? 充分的測試覆蓋率 ? 可讀性高的代碼； |
|
案例分析 ? 代碼閱讀：通過運用組合方法模式思想對代碼進行重構，進而演化為Template Method模式去除重復代碼 ? 代碼閱讀：分析面向?qū)ο笤O計方法所不能解決的重復問題，從而引入函數(shù)式思想去除重復 ? 郵件服務器：分析郵件服務器代碼暴露的問題，在可重用性、代碼可維護性、可擴展性等諸多方面著手，剖析代碼壞味道。 |
|
面向?qū)ο蟮脑O計要素 ? 合理封裝的要點 ? 迪米特法則 ? 繼承與委派的區(qū)別 ? 關注點分離原則 ? 多態(tài)與抽象 |
|
案例分析 ? 報表系統(tǒng)之參數(shù)處理：了解封裝的本質(zhì)，明確職責的分配以及智能對象的意義，理解“信息專家”模式。 ? 事務處理的設計：通過分析職責的承擔者，從而辨別職責的分配，并以組合橋接的方式進行抽象的分離。 ? 電子商務系統(tǒng)之訂單處理：對行為的封裝，職責的委派而非繼承的方式，進而重構到Command模式。 |
|
面向?qū)ο笤O計核心的SOLID原則 ? 單一職責原則（SRP）：該原則是合理封裝對象，分配職責的重要原則； ? 開放封閉原則（OCP）：該原則體現(xiàn)了擴展式開發(fā)的核心思想； ? Liskov替換原則（LSP）：可以將該原則視為是對是否正確運用繼承的檢驗標準； ? 接口隔離原則（ISP)：對于接口的粒度進行規(guī)劃，以便于設計出更好的接口； ? 依賴倒置原則（DCP）：對于依賴和解耦的分析，利用抽象保證設計的可擴展性； |
|
議題二：整潔代碼與重構 編寫整潔的代碼 ? 糟糕的代碼與混亂的代價，整潔代碼的藝術； ? 如何對變量、方法和類進行命名； ? 如何設計方法，遵循DRY與CQS原則； ? 如何進行錯誤處理和異常處理； ? 如何組織類和包； |
|
案例分析 給出真實項目中真實的代碼片段，對這些代碼進行分析，并利用整潔代碼的原則進行改善。這些代碼涉及到的問題包括：循環(huán)嵌套太多，方法命名不合理，缺乏足夠的封裝，性能問題； |
|
通過重構改善既有代碼 ? 破窗理論與重構的原則，包括重構與設計的關系，重構的時機和開展重構的原因 ? 介紹代碼的壞味道：詳細介紹各種代碼的壞味道，包括重復的代碼、過長函數(shù)、過大類、依戀情結、平行繼承體系、發(fā)散式變化、霰彈式修改等22種壞味道。 ? 介紹常見的重構手法，例如提取參數(shù)、提取方法、提取類、搬移方法、提取參數(shù)對象，以委托取代繼承等，并利用實際的案例展現(xiàn)如何對丑陋的代碼進行重構。 |
|
案例分析 對媒體管理系統(tǒng)的壞味道識別，利用重構改善代碼，并逐步引入Strategy模式與Visitor模式，進而改善設計。 |
|
議題三：合理的職責分配是良好設計的基礎 職責驅(qū)動設計 ? 職責的層次：包括職責層次的識別、職責層次與軟件架構層次之間的關系、職責與概念、規(guī)約與實現(xiàn) ? 對象的角色：角色、職責與協(xié)作是三位一體的關系，角色是發(fā)起職責的對象，職責則應該是對象之間的協(xié)作 ? 模塊級的職責分配：如何根據(jù)職責對模塊進行分解，了解高內(nèi)聚、松耦合原則。 |
|
案例分析 ? 對郵件服務器進行分析，通過分辨職責層次，來改善設計。并提出需求變更，從而引入對觀察者模式、策略模式、簡單工廠模式、調(diào)停者模式與職責鏈模式的對比與分析； ? 處理HTTP請求與應答，體現(xiàn)信息持有者角色； ? JMS對Queue的創(chuàng)建體現(xiàn)構造者角色； ? 稅務報告的生成體現(xiàn)服務提供者角色； ? 服務定位器體現(xiàn)協(xié)調(diào)者角色； ? 內(nèi)容驗證器體現(xiàn)控制者角色； ? EISaaS的模塊劃分； ? 基于AKKA的REST框架Spray； ? 國際報稅系統(tǒng)的架構演進，提出模塊重用的方式； |
|
職責分配遵循的原則與模式 ? 分析單一職責原則：分析該原則的核心思想，關注對象的變化點 ? 專家模式：專家模式的核心思想是信息的持有者是操作該信息的專家 ? 自治對象：分析了自治對象的特征，分別包括：最小完備，穩(wěn)定空間，自我履行與獨立進化 |
|
案例分析 ? 設備狀態(tài)的遷移：利用“自治對象”思想逐步引入State模式，并結合實際需求分析標準State模式的問題，從而對該模式進行改進 |
|
議題四：應對需求的變化，設計可擴展的軟件 如何應對需求的變化 ? 抽象的關鍵在于尋找多個對象（或行為）具有的共同特征，并對特性進行泛化 ? 函數(shù)式非凡的抽象能力 ? 識別變化點，對變化進行封裝 ? 解耦具體依賴：介紹常見的解除具體依賴的方法，包括表驅(qū)動法、配置與反射、IoC容器、慣例優(yōu)于配置 案例分析 ? 項目管理模型的抽象，通過對多種項目管理過程進行分析，對各種模型概念進行分類，并抽象出模型的共同特征，從而簡化模型； ? 電子商務系統(tǒng)的票據(jù)業(yè)務規(guī)則，引入Specification模式； ? CIMS系統(tǒng)的機器加載策略，引入Strategy模式； ? 短信服務，引入Facade模式與Adpater模式； ? 人力資源系統(tǒng)考勤模塊，介紹Gateway模式； ? URL Web請求，講解如何解耦具體依賴； |
|
擴展式設計 ? 擴展式設計的過程 |
|
案例分析 ? 消息隊列規(guī)范的設計：通過分析JMS、MSMQ的設計，理解抽象的含義，例如理解面向接口設計、接口隔離原則、按意圖設計、Facade模式； ? 保單問卷調(diào)查：講解如何從壞設計逐步重構到Visitor模式； |
|
議題五：設計模式的本質(zhì) 設計模式的境界 ? 初學者：拔劍四顧心茫然，不知道該如何運用設計模式 ? 熟練者：過尤不及，為模式而模式，常常導致設計過度 ? 精通者：無招勝有招，掌握了設計模式的本質(zhì)，能夠恰如其分地運用設計模式 |
|
設計的常見問題 ? 理論與設計無法有效結合 ? 過度運用設計模式 ? 急于編碼，沒有有效的設計 |
|
設計模式的本質(zhì) ? 合理的職責分配是基礎 ? 封裝并抽象變化是核心 ? 合理運用面向?qū)ο笤O計思想 ? 合理運用面向?qū)ο笤O計原則 |
|
案例分析：JUnit框架 通過全面剖析JUnit測試框架，了解大師的設計藝術，展現(xiàn)JUnit是如何保證框架的簡單、可擴展、可重用。內(nèi)容包括： ? JUnit的組件結構 ? JUnit的Test Case設計 ? 如何支持Test Result顯示的擴展 ? JUnit中如何通過復雜的設計來簡化用戶的使用 |
近期公開課推薦
