開發(fā)經(jīng)理
其他
軟件設(shè)計(jì)
推薦課程
average > 0 ? $model->average . '分' : '10.0分' ?>

卓越軟件設(shè)計(jì)匠藝

Bruce Zhang

前ThoughtWorks 架構(gòu)師、敏捷教練

先后就職于中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等?大型中外企
業(yè),任職?角?色為?高級軟件?工程師,架構(gòu)師,技術(shù)總監(jiān),?首席咨詢師?,F(xiàn)為深圳?
大眼科技有限公司的?首席架構(gòu)師,聯(lián)合創(chuàng)始?人。精通包括 C#、Java、Ruby、Scala、
Python、JavaScript 等多種語?言,熟練掌握?面向?qū)ο笏枷搿㈩I(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、函數(shù)式語
?言、架構(gòu)、?大數(shù)據(jù)分析、敏捷與過程改進(jìn),并致?力于?大型軟件企業(yè)的?面向服務(wù)系
統(tǒng)架構(gòu)設(shè)計(jì)以及互聯(lián)網(wǎng) Web 系統(tǒng)架構(gòu)設(shè)計(jì)。在 ThoughtWorks 期間,作為?一名咨詢師,
主要為客戶提供組織的敏捷轉(zhuǎn)型、過程改進(jìn)、系統(tǒng)架構(gòu)監(jiān)理、領(lǐng)域設(shè)計(jì)、代碼質(zhì)量提升等咨
詢?工作。目前,作為公司產(chǎn)品的架構(gòu)師,致力于商業(yè)智能產(chǎn)品與?大數(shù)據(jù)分析平臺的開發(fā)
與架構(gòu)設(shè)計(jì)

著譯作包括《解構(gòu)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》、《軟件設(shè)計(jì)精要與模式》、《架構(gòu)寶典》、《高可用可伸縮微服務(wù)架構(gòu)》、《Java設(shè)計(jì)模式》、《恰如其分的軟件架構(gòu)》、《WCF服務(wù)編程》、《人件》、《重構(gòu)——改善既有代碼設(shè)計(jì)》評注版、《架構(gòu)之美》評注版。

作為主持?人或講師多次被應(yīng)邀參加如中國軟件?大會、QCon、MPD 大會、
Agile China、Scrum Gathering 等?大型會議,并作為培訓(xùn)講師曾先后為摩托羅拉、惠普、
花旗銀?行、攜程、TCL、中興通訊、賽 門鐵克,廣發(fā)證券、平安銀?行等企業(yè)培訓(xùn)架構(gòu)、
設(shè)計(jì)、DDD、敏捷等專題內(nèi)容。著譯作包括《軟件設(shè)計(jì)精要與模式》、《Java 設(shè)計(jì)模式》、《恰如其分的軟件架構(gòu)》、《WCF 服務(wù)編程》、《?人件》等。目前,正在撰寫《架構(gòu)之
美(Beatiful Architecture)》評注版,即將出版。

先后就職于中興通訊、惠普 GDCC、中軟國際、ThoughtWorks 等?大型中外企 業(yè),任職?角?色為?高級軟件?工程師,架構(gòu)師,技術(shù)總監(jiān),?首席咨詢師?,F(xiàn)為深圳? 大眼科技有限公司的?首席架構(gòu)師,聯(lián)合創(chuàng)始?人。精通包括 C#、Java、Ruby、Scala、 Python、JavaScript 等多種語?言,熟練掌握?面向?qū)ο笏枷搿㈩I(lǐng)域驅(qū)動(dòng)設(shè)計(jì)、函數(shù)式語 ?言、架構(gòu)、?大數(shù)據(jù)分析、敏捷與過程改進(jìn),并致?力于?大型軟件企業(yè)的?面向服務(wù)系 統(tǒng)架構(gòu)設(shè)計(jì)以及互聯(lián)網(wǎng) Web 系統(tǒng)架構(gòu)設(shè)計(jì)。在 ThoughtWorks 期間,作為?一名咨詢師, 主要為客戶提供組織的敏捷轉(zhuǎn)型、過程改進(jìn)、系統(tǒng)架構(gòu)監(jiān)理、領(lǐng)域設(shè)計(jì)、代碼質(zhì)量提升等咨 詢?工作。目前,作為公司產(chǎn)品的架構(gòu)師,致力于商業(yè)智能產(chǎn)品與?大數(shù)據(jù)分析平臺的開發(fā) 與架構(gòu)設(shè)計(jì) 著譯作包括《解構(gòu)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》、《軟件設(shè)計(jì)精要與模式》、《架構(gòu)寶典》、《高可用可伸縮微服務(wù)架構(gòu)》、《Java設(shè)計(jì)模式》、《恰如其分的軟件架構(gòu)》、《WCF服務(wù)編程》、《人件》、《重構(gòu)——改善既有代碼設(shè)計(jì)》評注版、《架構(gòu)之美》評注版。 作為主持?人或講師多次被應(yīng)邀參加如中國軟件?大會、QCon、MPD 大會、 Agile China、Scrum Gathering 等?大型會議,并作為培訓(xùn)講師曾先后為摩托羅拉、惠普、 花旗銀?行、攜程、TCL、中興通訊、賽 門鐵克,廣發(fā)證券、平安銀?行等企業(yè)培訓(xùn)架構(gòu)、 設(shè)計(jì)、DDD、敏捷等專題內(nèi)容。著譯作包括《軟件設(shè)計(jì)精要與模式》、《Java 設(shè)計(jì)模式》、《恰如其分的軟件架構(gòu)》、《WCF 服務(wù)編程》、《?人件》等。目前,正在撰寫《架構(gòu)之 美(Beatiful Architecture)》評注版,即將出版。

課程費(fèi)用

5800.00 /人

課程時(shí)長

2

成為教練

課程簡介

1、全真案例,借助案例與設(shè)計(jì)模式知識的原理,借助最佳實(shí)踐,幫助您提高設(shè)計(jì)能力,從而提高開發(fā)效率和設(shè)計(jì)質(zhì)量
2、以新視角,揭示模式的本質(zhì)、思想方法,剖析出模式之“道”,跳出“為模式而模式”的“陷阱”
3、提升設(shè)計(jì)能力,使開發(fā)人員由“編程小工”到設(shè)計(jì)專家
4、提出場景驅(qū)動(dòng)設(shè)計(jì),利用領(lǐng)域建模、職責(zé)驅(qū)動(dòng)、擴(kuò)展式設(shè)計(jì)以及重構(gòu),提高軟件設(shè)計(jì)質(zhì)量,實(shí)現(xiàn)卓越軟件設(shè)計(jì)
5、關(guān)注業(yè)界內(nèi)設(shè)計(jì)模式,以實(shí)戰(zhàn)訓(xùn)練驅(qū)動(dòng)對面向?qū)ο笤O(shè)計(jì)的理解與運(yùn)用

目標(biāo)收益

1、員工無法接手遺留系統(tǒng),原因是代碼雜亂,可讀性差
2、團(tuán)隊(duì)成員沒有設(shè)計(jì)模式知識與經(jīng)驗(yàn),無法實(shí)施敏捷開發(fā)
3、系統(tǒng)難以重構(gòu),不利于產(chǎn)品的重用與二次開發(fā)
4、開發(fā)效率得不到保障,因?yàn)樵敿?xì)設(shè)計(jì)人員不能理解架構(gòu)文檔與詳細(xì)設(shè)計(jì)方案
5、設(shè)計(jì)方案難于應(yīng)對需求變更
6、設(shè)計(jì)的系統(tǒng)架構(gòu)缺乏可擴(kuò)展性、可維護(hù)性和可測試性,不能合理地重用
7、架構(gòu)、設(shè)計(jì)、開發(fā)三個(gè)環(huán)節(jié)中各個(gè)角色不能理解設(shè)計(jì)意圖,很難溝通

培訓(xùn)對象

IT人員

課程大綱

第一單元:
面向?qū)ο笤O(shè)計(jì):
角色、職責(zé)與協(xié)作
職責(zé)驅(qū)動(dòng)設(shè)計(jì)
面向?qū)ο笤O(shè)計(jì)的核心驅(qū)動(dòng)力是對象的職責(zé),合理的職責(zé)分配是卓越軟件設(shè)計(jì)的前提。只有合理地分辨對象的職責(zé),才能夠定義良好的對象,并實(shí)現(xiàn)符合系統(tǒng)一致性的對象協(xié)作關(guān)系。
1、職責(zé)的層次
通過職責(zé)層次模型對需求進(jìn)行分析,識別出業(yè)務(wù)價(jià)值、業(yè)務(wù)功能與業(yè)務(wù)實(shí)現(xiàn)。職責(zé)層次的分解可以有效地幫助設(shè)計(jì)者辨別職責(zé)。
(1)職責(zé)層次的識別
(2)職責(zé)層次與軟件架構(gòu)層次之間的關(guān)系
(3)職責(zé)與概念、規(guī)約與實(shí)現(xiàn)
(4)案例分析:分析郵件服務(wù)器代碼暴露的問題,在可重用性、代碼可維護(hù)性、可擴(kuò)展性等諸多方面著手,剖析代碼壞味道。通過分辨職責(zé)層次,來改善設(shè)計(jì)。并提出需求變更,從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析;
(5)實(shí)戰(zhàn)演練:設(shè)計(jì)一個(gè)作業(yè)調(diào)度框架,它能夠根據(jù)指定的時(shí)間觸發(fā)作業(yè),執(zhí)行自定義任務(wù)。

2、職責(zé)的分類
職責(zé)并不等于功能,也不等同于行為或方法。分析職責(zé),應(yīng)從對象的認(rèn)知與行為入手。

3、對象的角色
角色、職責(zé)與協(xié)作是三位一體的關(guān)系,角色是發(fā)起職責(zé)的對象,職責(zé)則應(yīng)該是對象之間的協(xié)作。不同角色的對象,履行的職責(zé)是不同的。
(1)信息持有者:信息的格式;是否需要持久化;信息源的改變,是否需要更新;處理信息的方式;
(2)構(gòu)造者:構(gòu)造者與構(gòu)造對象的關(guān)系;構(gòu)造的方式;聚合與合成;
(3)服務(wù)提供者:主動(dòng)告知,被動(dòng)告知;獨(dú)立的行為;提供有業(yè)務(wù)價(jià)值的行為;
(4)協(xié)調(diào)者:如何委派和轉(zhuǎn)發(fā)請求;如何通知其他對象要做的工作;如何通知狀態(tài)的變化;
(5)控制者:控制者與被控制者的關(guān)系;控制的決策與邏輯;驅(qū)動(dòng)其他對象;收集與決策有關(guān)的信息;
(6)案例:處理HTTP請求與應(yīng)答,體現(xiàn)信息持有者角色;JMS對Queue的創(chuàng)建體現(xiàn)構(gòu)造者角色;稅務(wù)報(bào)告的生成體現(xiàn)服務(wù)提供者角色;服務(wù)定位器體現(xiàn)協(xié)調(diào)者角色;內(nèi)容驗(yàn)證器體現(xiàn)控制者角色;

4、職責(zé)與封裝的關(guān)系
缺乏合理的封裝,就會缺少正確的領(lǐng)域?qū)ο?,從而?dǎo)致領(lǐng)域信息散亂分布到系統(tǒng)各個(gè)方法,使得概念不夠清晰,導(dǎo)致職責(zé)混亂。

5、模塊級的職責(zé)分配
(1)問題分析:模塊之間職責(zé)的分配,在面臨三種問題時(shí),應(yīng)該如何應(yīng)對?通過對具體問題的分析,討論模塊之間的職責(zé)分配,以及對高內(nèi)聚、松耦合的理解。同時(shí),該問題分析還將引入Template Method模式;
(2)問題分析:錯(cuò)誤的職責(zé)分配帶來的循環(huán)依賴問題,以及對包的復(fù)用原則的違背,提出解決辦法;
(3)模塊重用:對eBay模塊的分析,以及對某大型系統(tǒng)架構(gòu)的演進(jìn),提出模塊重用的方式;

6、原則與模式
(1)單一職責(zé)原則:分析該原則的核心思想,關(guān)注對象的變化點(diǎn);
(2)案例分析:功能引擎中對功能對象的加載,如何體現(xiàn)職責(zé)分離帶來的好處;通過對案例分析引入Proxy模式;
(3)專家模式:專家模式的核心思想是信息的持有者是操作該信息的專家;
(4)案例分析:報(bào)表參數(shù)的處理方式,如何通過識別設(shè)計(jì)違背了專家模式,并依據(jù)專家模式對設(shè)計(jì)進(jìn)行改進(jìn),從而巧妙地利用多態(tài)消除代碼壞味道,并進(jìn)而通過引入Adapter模式處理模塊之間的依賴關(guān)系;
(5)自治對象:分析了自治對象的特征,分別包括:最小完備,穩(wěn)定空間,自我履行與獨(dú)立進(jìn)化。
(6)案例分析:用戶狀態(tài)機(jī),給出了某金融系統(tǒng)中復(fù)雜的用戶狀態(tài)遷移,體現(xiàn)的復(fù)雜授權(quán)、登錄等業(yè)務(wù)邏輯,并由此引入State模式來簡化設(shè)計(jì),體現(xiàn)自治對象的特征。
第二單元
面向?qū)ο笤O(shè)計(jì):
抽象與變化
擴(kuò)展式設(shè)計(jì)
合理的職責(zé)分配并不能完全保證軟件設(shè)計(jì)的卓越,因?yàn)樾枨笞兓擒浖_發(fā)的常態(tài),因此設(shè)計(jì)必須在一定程度滿足變化,保證系統(tǒng)的可擴(kuò)展性。
1、抽象的意義
抽象的關(guān)鍵在于尋找多個(gè)對象(或行為)具有的共同特征,并對特性進(jìn)行泛化。泛化的特征可以暴露在外,從而隔離內(nèi)部的實(shí)現(xiàn)。
(1)用例分析:對用例和參與者的泛化;遵循的原則;
(2)案例分析:授權(quán)框架的設(shè)計(jì),體現(xiàn)了對共同特征的提取,合理引入Chain Of Responsibility模式與Template Method模式;
(3)案例分析:項(xiàng)目管理模型的抽象,通過對多種項(xiàng)目管理過程進(jìn)行分析,對各種模型概念進(jìn)行分類,并抽象出模型的共同特征,從而簡化模型;

2、識別變化
要保證設(shè)計(jì)的可擴(kuò)展性,主要過程是識別變化點(diǎn),然后對變化進(jìn)行封裝。
(1)變化點(diǎn):常見的變化點(diǎn)包括業(yè)務(wù)規(guī)則、算法策略、外部服務(wù)、硬件支持、命令請求、協(xié)議標(biāo)準(zhǔn)、數(shù)據(jù)格式、業(yè)務(wù)流程、系統(tǒng)配置、界面表現(xiàn);
(2)案例分析:電子商務(wù)系統(tǒng)的Invoice業(yè)務(wù)規(guī)則,引入Specification模式;CIMS系統(tǒng)的機(jī)器加載策略,引入Strategy模式;短信服務(wù),引入Facade模式與Adapter模式;人力資源系統(tǒng)考勤模塊,引入Gateway模式;
(3)案例分析:CQRS框架,對命令處理邏輯的包裝,引入Decorator模式,并通過分析變化點(diǎn),引入另一種替代Decorator模式的設(shè)計(jì)。

3、依賴解耦
處理變化的關(guān)鍵是要解除對具體對象的依賴。
(1)表驅(qū)動(dòng)法
(2)配置與反射
(3)IoC容器
(4)慣例優(yōu)于配置

4、擴(kuò)展式設(shè)計(jì)
擴(kuò)展式設(shè)計(jì)分為三個(gè)步驟,分別為:分離職責(zé)各司其職,利用抽象統(tǒng)一接口,引用接口預(yù)留空白。擴(kuò)展式設(shè)計(jì)可以有效地保證整個(gè)系統(tǒng)的可擴(kuò)展性。
(1)擴(kuò)展式設(shè)計(jì)的步驟
(2)實(shí)戰(zhàn)演練:訂單處理,通過三次迭代逐步改進(jìn)原有設(shè)計(jì),并分別遵循專家模式、分離原則與擴(kuò)展式設(shè)計(jì),保證設(shè)計(jì)在修改最小的前提下滿足需求變化。在設(shè)計(jì)演進(jìn)中,討論對設(shè)計(jì)模式的合理運(yùn)用,并引入Specification模式;
(3)案例分析:配置管理框架的設(shè)計(jì),該框架能夠支持配置信息的多種存儲形態(tài),包括文件、數(shù)據(jù)庫、LDAP等;支持多種獲取配置的方式,如Web服務(wù),REST服務(wù)。配置管理框架的接口需要保證其統(tǒng)一性和一致性,同時(shí)在滿足可擴(kuò)展要求下,提供接口的易用性。
(4)案例分析:消息隊(duì)列規(guī)范的設(shè)計(jì)。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設(shè)計(jì),理解抽象的含義,例如理解面向接口設(shè)計(jì)、接口隔離原則、按意圖設(shè)計(jì)、Facade模式與企業(yè)集成模式。
(5)實(shí)戰(zhàn)演練:CIMS基于消息的分布式架構(gòu)。通過對服務(wù)的統(tǒng)一抽象,以及對消息處理的職責(zé)分配,建立一個(gè)協(xié)作合理的分布式架構(gòu)。設(shè)計(jì)過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。
第三單元
場景驅(qū)動(dòng)設(shè)計(jì):
利用場景建模
設(shè)計(jì)過程
無論進(jìn)行怎樣的設(shè)計(jì),都不能離開具體的場景。場景驅(qū)動(dòng)設(shè)計(jì)的要義是基于場景有針對性地進(jìn)行設(shè)計(jì)。場景既是設(shè)計(jì)的驅(qū)動(dòng)力,又是設(shè)計(jì)的約束,從而獲得恰如其分的設(shè)計(jì)。
1、場景的目標(biāo)層次
(1)概要目標(biāo):系統(tǒng)層次的場景劃分,每個(gè)概要目標(biāo)可對應(yīng)子系統(tǒng)的需求目標(biāo)。通過概要目標(biāo)引入領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的Unbounded Context。
(2)用戶目標(biāo):業(yè)務(wù)層次的場景劃分,每個(gè)用戶目標(biāo)對應(yīng)各個(gè)子系統(tǒng)所提供的業(yè)務(wù)價(jià)值,并以服務(wù)的形式暴露給調(diào)用者。
(3)子功能:功能層次的場景劃分,每個(gè)子功能都對應(yīng)于業(yè)務(wù)功能,并以領(lǐng)域?qū)ο蠡驒M切關(guān)注點(diǎn)的方式,由服務(wù)調(diào)用。
(4)案例分析:電子商務(wù)系統(tǒng)的場景目標(biāo)劃分,以層次模型的方式表現(xiàn)場景。

2、場景的6W模型
(1)6W的內(nèi)容:分別為who(對應(yīng)于角色)、why(對應(yīng)于業(yè)務(wù)價(jià)值)、when(對應(yīng)于對象的協(xié)作)、what(對應(yīng)于業(yè)務(wù)功能)、where(對應(yīng)于場景邊界)和hoW(對應(yīng)于業(yè)務(wù)實(shí)現(xiàn));
(2)6W模型的設(shè)計(jì)驅(qū)動(dòng)力:6W模型的關(guān)鍵是在場景邊界內(nèi),通過場景識別出角色,再以角色為設(shè)計(jì)入口,運(yùn)用職責(zé)的層次模型識別出業(yè)務(wù)價(jià)值、業(yè)務(wù)功能和業(yè)務(wù)實(shí)現(xiàn),從而根據(jù)職責(zé)模型獲得領(lǐng)域模型,再通過時(shí)序圖,處理對象之間的協(xié)作關(guān)系,進(jìn)一步精煉出更為準(zhǔn)確的領(lǐng)域模型。

3、場景驅(qū)動(dòng)設(shè)計(jì)演練
(1)實(shí)戰(zhàn)案例:某大型跨國公司的內(nèi)部培訓(xùn)系統(tǒng),包括培訓(xùn)計(jì)劃制訂,培訓(xùn)實(shí)施以及員工職業(yè)生涯規(guī)劃等功能;
(2)對整個(gè)系統(tǒng)進(jìn)行分析,識別場景的目標(biāo)層次;
(3)劃分需求場景,運(yùn)用6W模型進(jìn)行場景驅(qū)動(dòng)設(shè)計(jì);
場景一:將培訓(xùn)的Ticket分配給員工。在分配ticket時(shí),需要指定deadline,以及取消票或deadline到期時(shí)的Action。同時(shí),將該ticket的狀態(tài)設(shè)置為pending;
場景二:在接收到分配ticket的通知后,并在設(shè)定的deadline之前,拒絕該ticket。此時(shí),會自動(dòng)執(zhí)行事先分配給ticket的取消票的action;
場景三:根據(jù)設(shè)定的trigger周期,定期掃描在當(dāng)日滿足deadline條件的ticket;如果存在滿足deadline條件的ticket,且ticket的狀態(tài)不為accepted,則需要觸發(fā)事先指定給該ticket的action。
場景四:無論是nomination,還是接收ticket、取消ticket,或者deadline以及取消執(zhí)行的action,只要是對ticket進(jìn)行了處理,都需要記錄這次處理ticket的記錄,以便于未來對該票的跟蹤;
整個(gè)演練將完整介紹場景驅(qū)動(dòng)設(shè)計(jì)的過程,并結(jié)合前面講解的職責(zé)驅(qū)動(dòng)設(shè)計(jì)與擴(kuò)展式設(shè)計(jì),確保優(yōu)良的設(shè)計(jì)。案例會引入對領(lǐng)域建模的考量,識別職責(zé)、識別變化點(diǎn)并封裝變化。設(shè)計(jì)會引入Strategy模式,Bridge模式、Repository模式、State模式以及Interceptor模式等,使設(shè)計(jì)滿足可重用性、可擴(kuò)展性。

4、卓越的軟件設(shè)計(jì)
整個(gè)設(shè)計(jì)過程是由場景來驅(qū)動(dòng),通過角色識別職責(zé),然后遵循高內(nèi)聚原則對對象進(jìn)行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中,可通過識別變化點(diǎn),利用抽象對變化進(jìn)行封裝。卓越的軟件設(shè)計(jì)還需要不斷地演進(jìn),保證設(shè)計(jì)達(dá)到卓越的途徑是識別壞味道,然后通過重構(gòu)對代碼進(jìn)行改進(jìn);還可以運(yùn)用探索式設(shè)計(jì),對職責(zé)進(jìn)行合理的分配。
(1)常見的壞味道:包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等;
(2)探索式方法:包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內(nèi)部關(guān)系、尋找主要職責(zé)、草稿式重構(gòu)與關(guān)注當(dāng)前工作。
(3)卓越軟件設(shè)計(jì)模型
第一單元:
面向?qū)ο笤O(shè)計(jì):
角色、職責(zé)與協(xié)作
職責(zé)驅(qū)動(dòng)設(shè)計(jì)
面向?qū)ο笤O(shè)計(jì)的核心驅(qū)動(dòng)力是對象的職責(zé),合理的職責(zé)分配是卓越軟件設(shè)計(jì)的前提。只有合理地分辨對象的職責(zé),才能夠定義良好的對象,并實(shí)現(xiàn)符合系統(tǒng)一致性的對象協(xié)作關(guān)系。
1、職責(zé)的層次
通過職責(zé)層次模型對需求進(jìn)行分析,識別出業(yè)務(wù)價(jià)值、業(yè)務(wù)功能與業(yè)務(wù)實(shí)現(xiàn)。職責(zé)層次的分解可以有效地幫助設(shè)計(jì)者辨別職責(zé)。
(1)職責(zé)層次的識別
(2)職責(zé)層次與軟件架構(gòu)層次之間的關(guān)系
(3)職責(zé)與概念、規(guī)約與實(shí)現(xiàn)
(4)案例分析:分析郵件服務(wù)器代碼暴露的問題,在可重用性、代碼可維護(hù)性、可擴(kuò)展性等諸多方面著手,剖析代碼壞味道。通過分辨職責(zé)層次,來改善設(shè)計(jì)。并提出需求變更,從而引入對Observer模式、Strategy模式、Simple Factory模式、Mediator模式與Chain Of Responsibility模式的對比與分析;
(5)實(shí)戰(zhàn)演練:設(shè)計(jì)一個(gè)作業(yè)調(diào)度框架,它能夠根據(jù)指定的時(shí)間觸發(fā)作業(yè),執(zhí)行自定義任務(wù)。

2、職責(zé)的分類
職責(zé)并不等于功能,也不等同于行為或方法。分析職責(zé),應(yīng)從對象的認(rèn)知與行為入手。

3、對象的角色
角色、職責(zé)與協(xié)作是三位一體的關(guān)系,角色是發(fā)起職責(zé)的對象,職責(zé)則應(yīng)該是對象之間的協(xié)作。不同角色的對象,履行的職責(zé)是不同的。
(1)信息持有者:信息的格式;是否需要持久化;信息源的改變,是否需要更新;處理信息的方式;
(2)構(gòu)造者:構(gòu)造者與構(gòu)造對象的關(guān)系;構(gòu)造的方式;聚合與合成;
(3)服務(wù)提供者:主動(dòng)告知,被動(dòng)告知;獨(dú)立的行為;提供有業(yè)務(wù)價(jià)值的行為;
(4)協(xié)調(diào)者:如何委派和轉(zhuǎn)發(fā)請求;如何通知其他對象要做的工作;如何通知狀態(tài)的變化;
(5)控制者:控制者與被控制者的關(guān)系;控制的決策與邏輯;驅(qū)動(dòng)其他對象;收集與決策有關(guān)的信息;
(6)案例:處理HTTP請求與應(yīng)答,體現(xiàn)信息持有者角色;JMS對Queue的創(chuàng)建體現(xiàn)構(gòu)造者角色;稅務(wù)報(bào)告的生成體現(xiàn)服務(wù)提供者角色;服務(wù)定位器體現(xiàn)協(xié)調(diào)者角色;內(nèi)容驗(yàn)證器體現(xiàn)控制者角色;

4、職責(zé)與封裝的關(guān)系
缺乏合理的封裝,就會缺少正確的領(lǐng)域?qū)ο?,從而?dǎo)致領(lǐng)域信息散亂分布到系統(tǒng)各個(gè)方法,使得概念不夠清晰,導(dǎo)致職責(zé)混亂。

5、模塊級的職責(zé)分配
(1)問題分析:模塊之間職責(zé)的分配,在面臨三種問題時(shí),應(yīng)該如何應(yīng)對?通過對具體問題的分析,討論模塊之間的職責(zé)分配,以及對高內(nèi)聚、松耦合的理解。同時(shí),該問題分析還將引入Template Method模式;
(2)問題分析:錯(cuò)誤的職責(zé)分配帶來的循環(huán)依賴問題,以及對包的復(fù)用原則的違背,提出解決辦法;
(3)模塊重用:對eBay模塊的分析,以及對某大型系統(tǒng)架構(gòu)的演進(jìn),提出模塊重用的方式;

6、原則與模式
(1)單一職責(zé)原則:分析該原則的核心思想,關(guān)注對象的變化點(diǎn);
(2)案例分析:功能引擎中對功能對象的加載,如何體現(xiàn)職責(zé)分離帶來的好處;通過對案例分析引入Proxy模式;
(3)專家模式:專家模式的核心思想是信息的持有者是操作該信息的專家;
(4)案例分析:報(bào)表參數(shù)的處理方式,如何通過識別設(shè)計(jì)違背了專家模式,并依據(jù)專家模式對設(shè)計(jì)進(jìn)行改進(jìn),從而巧妙地利用多態(tài)消除代碼壞味道,并進(jìn)而通過引入Adapter模式處理模塊之間的依賴關(guān)系;
(5)自治對象:分析了自治對象的特征,分別包括:最小完備,穩(wěn)定空間,自我履行與獨(dú)立進(jìn)化。
(6)案例分析:用戶狀態(tài)機(jī),給出了某金融系統(tǒng)中復(fù)雜的用戶狀態(tài)遷移,體現(xiàn)的復(fù)雜授權(quán)、登錄等業(yè)務(wù)邏輯,并由此引入State模式來簡化設(shè)計(jì),體現(xiàn)自治對象的特征。
第二單元
面向?qū)ο笤O(shè)計(jì):
抽象與變化
擴(kuò)展式設(shè)計(jì)
合理的職責(zé)分配并不能完全保證軟件設(shè)計(jì)的卓越,因?yàn)樾枨笞兓擒浖_發(fā)的常態(tài),因此設(shè)計(jì)必須在一定程度滿足變化,保證系統(tǒng)的可擴(kuò)展性。
1、抽象的意義
抽象的關(guān)鍵在于尋找多個(gè)對象(或行為)具有的共同特征,并對特性進(jìn)行泛化。泛化的特征可以暴露在外,從而隔離內(nèi)部的實(shí)現(xiàn)。
(1)用例分析:對用例和參與者的泛化;遵循的原則;
(2)案例分析:授權(quán)框架的設(shè)計(jì),體現(xiàn)了對共同特征的提取,合理引入Chain Of Responsibility模式與Template Method模式;
(3)案例分析:項(xiàng)目管理模型的抽象,通過對多種項(xiàng)目管理過程進(jìn)行分析,對各種模型概念進(jìn)行分類,并抽象出模型的共同特征,從而簡化模型;

2、識別變化
要保證設(shè)計(jì)的可擴(kuò)展性,主要過程是識別變化點(diǎn),然后對變化進(jìn)行封裝。
(1)變化點(diǎn):常見的變化點(diǎn)包括業(yè)務(wù)規(guī)則、算法策略、外部服務(wù)、硬件支持、命令請求、協(xié)議標(biāo)準(zhǔn)、數(shù)據(jù)格式、業(yè)務(wù)流程、系統(tǒng)配置、界面表現(xiàn);
(2)案例分析:電子商務(wù)系統(tǒng)的Invoice業(yè)務(wù)規(guī)則,引入Specification模式;CIMS系統(tǒng)的機(jī)器加載策略,引入Strategy模式;短信服務(wù),引入Facade模式與Adapter模式;人力資源系統(tǒng)考勤模塊,引入Gateway模式;
(3)案例分析:CQRS框架,對命令處理邏輯的包裝,引入Decorator模式,并通過分析變化點(diǎn),引入另一種替代Decorator模式的設(shè)計(jì)。

3、依賴解耦
處理變化的關(guān)鍵是要解除對具體對象的依賴。
(1)表驅(qū)動(dòng)法
(2)配置與反射
(3)IoC容器
(4)慣例優(yōu)于配置

4、擴(kuò)展式設(shè)計(jì)
擴(kuò)展式設(shè)計(jì)分為三個(gè)步驟,分別為:分離職責(zé)各司其職,利用抽象統(tǒng)一接口,引用接口預(yù)留空白。擴(kuò)展式設(shè)計(jì)可以有效地保證整個(gè)系統(tǒng)的可擴(kuò)展性。
(1)擴(kuò)展式設(shè)計(jì)的步驟
(2)實(shí)戰(zhàn)演練:訂單處理,通過三次迭代逐步改進(jìn)原有設(shè)計(jì),并分別遵循專家模式、分離原則與擴(kuò)展式設(shè)計(jì),保證設(shè)計(jì)在修改最小的前提下滿足需求變化。在設(shè)計(jì)演進(jìn)中,討論對設(shè)計(jì)模式的合理運(yùn)用,并引入Specification模式;
(3)案例分析:配置管理框架的設(shè)計(jì),該框架能夠支持配置信息的多種存儲形態(tài),包括文件、數(shù)據(jù)庫、LDAP等;支持多種獲取配置的方式,如Web服務(wù),REST服務(wù)。配置管理框架的接口需要保證其統(tǒng)一性和一致性,同時(shí)在滿足可擴(kuò)展要求下,提供接口的易用性。
(4)案例分析:消息隊(duì)列規(guī)范的設(shè)計(jì)。通過分析JMS、MSMQ、RabbitMQ和NServiceBus的設(shè)計(jì),理解抽象的含義,例如理解面向接口設(shè)計(jì)、接口隔離原則、按意圖設(shè)計(jì)、Facade模式與企業(yè)集成模式。
(5)實(shí)戰(zhàn)演練:CIMS基于消息的分布式架構(gòu)。通過對服務(wù)的統(tǒng)一抽象,以及對消息處理的職責(zé)分配,建立一個(gè)協(xié)作合理的分布式架構(gòu)。設(shè)計(jì)過程中會引入Command模式、Publisher – Subscriber模式、Message Bus模式、Message Translator模式、Lookup模式。
第三單元
場景驅(qū)動(dòng)設(shè)計(jì):
利用場景建模
設(shè)計(jì)過程
無論進(jìn)行怎樣的設(shè)計(jì),都不能離開具體的場景。場景驅(qū)動(dòng)設(shè)計(jì)的要義是基于場景有針對性地進(jìn)行設(shè)計(jì)。場景既是設(shè)計(jì)的驅(qū)動(dòng)力,又是設(shè)計(jì)的約束,從而獲得恰如其分的設(shè)計(jì)。
1、場景的目標(biāo)層次
(1)概要目標(biāo):系統(tǒng)層次的場景劃分,每個(gè)概要目標(biāo)可對應(yīng)子系統(tǒng)的需求目標(biāo)。通過概要目標(biāo)引入領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的Unbounded Context。
(2)用戶目標(biāo):業(yè)務(wù)層次的場景劃分,每個(gè)用戶目標(biāo)對應(yīng)各個(gè)子系統(tǒng)所提供的業(yè)務(wù)價(jià)值,并以服務(wù)的形式暴露給調(diào)用者。
(3)子功能:功能層次的場景劃分,每個(gè)子功能都對應(yīng)于業(yè)務(wù)功能,并以領(lǐng)域?qū)ο蠡驒M切關(guān)注點(diǎn)的方式,由服務(wù)調(diào)用。
(4)案例分析:電子商務(wù)系統(tǒng)的場景目標(biāo)劃分,以層次模型的方式表現(xiàn)場景。

2、場景的6W模型
(1)6W的內(nèi)容:分別為who(對應(yīng)于角色)、why(對應(yīng)于業(yè)務(wù)價(jià)值)、when(對應(yīng)于對象的協(xié)作)、what(對應(yīng)于業(yè)務(wù)功能)、where(對應(yīng)于場景邊界)和hoW(對應(yīng)于業(yè)務(wù)實(shí)現(xiàn));
(2)6W模型的設(shè)計(jì)驅(qū)動(dòng)力:6W模型的關(guān)鍵是在場景邊界內(nèi),通過場景識別出角色,再以角色為設(shè)計(jì)入口,運(yùn)用職責(zé)的層次模型識別出業(yè)務(wù)價(jià)值、業(yè)務(wù)功能和業(yè)務(wù)實(shí)現(xiàn),從而根據(jù)職責(zé)模型獲得領(lǐng)域模型,再通過時(shí)序圖,處理對象之間的協(xié)作關(guān)系,進(jìn)一步精煉出更為準(zhǔn)確的領(lǐng)域模型。

3、場景驅(qū)動(dòng)設(shè)計(jì)演練
(1)實(shí)戰(zhàn)案例:某大型跨國公司的內(nèi)部培訓(xùn)系統(tǒng),包括培訓(xùn)計(jì)劃制訂,培訓(xùn)實(shí)施以及員工職業(yè)生涯規(guī)劃等功能;
(2)對整個(gè)系統(tǒng)進(jìn)行分析,識別場景的目標(biāo)層次;
(3)劃分需求場景,運(yùn)用6W模型進(jìn)行場景驅(qū)動(dòng)設(shè)計(jì);
場景一:將培訓(xùn)的Ticket分配給員工。在分配ticket時(shí),需要指定deadline,以及取消票或deadline到期時(shí)的Action。同時(shí),將該ticket的狀態(tài)設(shè)置為pending;
場景二:在接收到分配ticket的通知后,并在設(shè)定的deadline之前,拒絕該ticket。此時(shí),會自動(dòng)執(zhí)行事先分配給ticket的取消票的action;
場景三:根據(jù)設(shè)定的trigger周期,定期掃描在當(dāng)日滿足deadline條件的ticket;如果存在滿足deadline條件的ticket,且ticket的狀態(tài)不為accepted,則需要觸發(fā)事先指定給該ticket的action。
場景四:無論是nomination,還是接收ticket、取消ticket,或者deadline以及取消執(zhí)行的action,只要是對ticket進(jìn)行了處理,都需要記錄這次處理ticket的記錄,以便于未來對該票的跟蹤;
整個(gè)演練將完整介紹場景驅(qū)動(dòng)設(shè)計(jì)的過程,并結(jié)合前面講解的職責(zé)驅(qū)動(dòng)設(shè)計(jì)與擴(kuò)展式設(shè)計(jì),確保優(yōu)良的設(shè)計(jì)。案例會引入對領(lǐng)域建模的考量,識別職責(zé)、識別變化點(diǎn)并封裝變化。設(shè)計(jì)會引入Strategy模式,Bridge模式、Repository模式、State模式以及Interceptor模式等,使設(shè)計(jì)滿足可重用性、可擴(kuò)展性。

4、卓越的軟件設(shè)計(jì)
整個(gè)設(shè)計(jì)過程是由場景來驅(qū)動(dòng),通過角色識別職責(zé),然后遵循高內(nèi)聚原則對對象進(jìn)行封裝。合理的封裝還必須保證對象之間的協(xié)作是松耦合。其中,可通過識別變化點(diǎn),利用抽象對變化進(jìn)行封裝。卓越的軟件設(shè)計(jì)還需要不斷地演進(jìn),保證設(shè)計(jì)達(dá)到卓越的途徑是識別壞味道,然后通過重構(gòu)對代碼進(jìn)行改進(jìn);還可以運(yùn)用探索式設(shè)計(jì),對職責(zé)進(jìn)行合理的分配。
(1)常見的壞味道:包括過長方法、過大的類、特性依戀、霰彈式修改、消息鏈、并行的繼承體系、中間人等;
(2)探索式方法:包括方法分組、觀察隱藏方法、尋找可以更改的決定、尋找內(nèi)部關(guān)系、尋找主要職責(zé)、草稿式重構(gòu)與關(guān)注當(dāng)前工作。
(3)卓越軟件設(shè)計(jì)模型

活動(dòng)詳情

提交需求