從混亂到有序
1 Layers模式
采用分層的設(shè)計(jì)思想盗棵，如tcp/ip協(xié)議棧的實(shí)現(xiàn)：
代碼結(jié)構(gòu)類似如下衔蹲，當(dāng)然還有變種
classL1Provider{
public:
virtual voidl1Service() =0;
};classL2Provider{
public:
virtual voidl2Service() =0;
voidsetL1Provider(L1Provider*provider){this->provider= provider;};
protected:
L1Provider*provider;
};
classL3Provider{
public:
virtual voidl3Service() =0;
voidsetL2Provider(L2Provider*provider){this->provider= provider;}
protected:
L2Provider*provider;
};
classDataLink:publicL1Provider{
public:
virtual voidl1Service(){
cout<<"L1 service doing it jobs"<
}
};
classTranspot:publicL2Provider{
virtual voidl2Service(){
cout<<"L2 service before doing it jobs"<
provider->l1Service();
cout<<"L2 service after doing it jobs"<
}
};
classSession:publicL3Provider{
virtual voidl3Service(){
cout<<"L3 service before doing it jobs"<
provider->l2Service();
cout<<"L3 service after doing it jobs"<
}
};
優(yōu)點(diǎn)：各層可重用 支持標(biāo)準(zhǔn)化 限制了依賴關(guān)系范圍? 可更換性
缺點(diǎn)：行為變化可能引起雪崩效應(yīng) 效率低下 不必要的工作? 難以確定正確的層次粒度
2 Pipes and filter （流水線斩祭，管道與過(guò)濾器模型）
提供類似unix的管道（|）對(duì)數(shù)據(jù)處理的架構(gòu)界阁，將數(shù)據(jù)寫(xiě)入管道，下一個(gè)filter進(jìn)行處理 长窄，并寫(xiě)入另一個(gè)管道。
有如下幾種情景
1
2 情景2 拉取模型
情景3 推拉模型 中間filter主動(dòng)請(qǐng)求數(shù)據(jù)并推送數(shù)據(jù)
4 情景4 并行模式 所有filter都主動(dòng)拉取，輪詢屬于自己的管道
優(yōu)點(diǎn)：不需要中間文件忠聚，但也可以使用 ? 可更換過(guò)濾器 ? 可重組過(guò)濾器 ?可重用過(guò)濾器 ?可快速創(chuàng)建流水線原型 ?效率因并行處理所提高
缺點(diǎn)：狀態(tài)信息的開(kāi)銷高昂或缺乏靈活性 ?通過(guò)并行提高效率的初衷常為泡影 ?數(shù)據(jù)轉(zhuǎn)換開(kāi)銷大 ?錯(cuò)誤處理
3BlackBoard （黑板模式）
未找到解決辦法的不成熟領(lǐng)域，如語(yǔ)音識(shí)別 圖下識(shí)別 監(jiān)視等唱捣，該問(wèn)題具有如下特點(diǎn)： 可分解成多個(gè)子問(wèn)題两蟀，但每個(gè)子問(wèn)題都屬于多個(gè)不同專業(yè)領(lǐng)域。要解決子問(wèn)題震缭，需要使用不同的表示方法和范式赂毯。再很多情況下都沒(méi)有指導(dǎo)子問(wèn)題解決者如何系統(tǒng)作戰(zhàn)的既定策略，者與職責(zé)分解形成了鮮明的對(duì)比拣宰，在執(zhí)飛分解中党涕，按指定順序啟動(dòng)多個(gè)解決步驟。
該框架結(jié)構(gòu)分為三部分： 控制組建 黑板組建 知識(shí)源
control用于確定下一個(gè)使用的知識(shí)源巡社，確定下一個(gè)知識(shí)源需要使用知識(shí)源判斷自己是否能處理黑板組建上的結(jié)果膛堤，黑板組建責(zé)用于幾率知識(shí)源產(chǎn)生的結(jié)果。
優(yōu)點(diǎn)：可以驗(yàn)證 ?有助于提高可修改性和可維護(hù)性 知識(shí)源課重用 可提高容錯(cuò)能力和健壯性
缺點(diǎn)：難以測(cè)試 ?不保證能提供滿意的解 難以制定上號(hào)的策略 效率低 開(kāi)發(fā)工作量大 ?不支持并行
分布式系統(tǒng)
分布式系統(tǒng)的優(yōu)點(diǎn)： 經(jīng)濟(jì)實(shí)惠 性能和可擴(kuò)展性 固有分配行 可靠性
1 Broker(中間人模式)
組件圖
該模式主要有三部分 ?client broker ?server 晌该。 client用于發(fā)起請(qǐng)求 broker用于分發(fā)服務(wù)肥荔，server用于處理請(qǐng)求绿渣， 另外client proxy是屬于client部分，用處對(duì)數(shù)據(jù)進(jìn)行額外處理燕耿，同樣server provy屬于server部分中符。 bridge的意圖時(shí)用于 將三部分接偶，可通過(guò)不同的bridge導(dǎo)向不同的server和client （其實(shí)android中binder就是一個(gè)這樣的結(jié)構(gòu) binder驅(qū)動(dòng)就是中間人）
存在以下幾個(gè)情景
1情景1 ?服務(wù)向中間人注冊(cè)
情景2 ?客戶端向本地服務(wù)發(fā)送請(qǐng)求
情景3 不同中間人通過(guò)網(wǎng)絡(luò)交互
優(yōu)點(diǎn)：位置透明誉帅，組件可修改可擴(kuò)展 可移植 ?不同broker系統(tǒng)之間的互操作性 可重用性
缺點(diǎn)：效率不高淀散，容錯(cuò)性差 測(cè)試和調(diào)試?yán)щy
交互式系統(tǒng)
人機(jī)交互西東，多為含有界面的程序
交互式系統(tǒng)開(kāi)發(fā)起來(lái)比較容易堵第，因?yàn)槿斯げ僮鞣稚⒘诉壿?/p>
Mode-View-Controller（mvc）模式
常見(jiàn)的gui程序幾乎都屬于mvc模式或mvc模式變種
該模式分為三部分吧凉，數(shù)據(jù)模型，控制器踏志，界面阀捅， 界面用于顯示數(shù)據(jù)，并且通過(guò)界面?zhèn)鬟f事件給控制器處理邏輯针余，更新數(shù)據(jù)饲鄙，數(shù)據(jù)變化又出發(fā)控制器更新界面。
組件
動(dòng)態(tài)：?
情景1 用戶輸入導(dǎo)致模型變化圆雁，進(jìn)而出發(fā)變更傳播機(jī)制
情景2 ?組件初始化
優(yōu)點(diǎn)：一個(gè)模型可以有多個(gè)視圖忍级，視圖同步，可插入的視圖和控制器伪朽，可更換外觀轴咱，可開(kāi)發(fā)框架
缺點(diǎn)：更復(fù)雜 更新可能過(guò)度頻繁 視圖和控制器關(guān)系緊密 視圖和控制器與模型耦合 視圖和控制器訪問(wèn)效率底下，移植必須修改視圖和控制器 使用較新的用戶界面工具時(shí)難以遵循mvc
presentation-Abstraction-Contril(PAC)模式
定義了一種適用于交互式系統(tǒng)的結(jié)構(gòu)－由相互協(xié)作的只能體組成的層次結(jié)構(gòu)烈涮。每個(gè)只能體都負(fù)責(zé)應(yīng)用程序功能的特定方面朴肺，并包含三個(gè)組件：表示組件，抽象組件和控制組件坚洽，這將只能的人機(jī)交互方向功能核心同通信分離
注意整個(gè)系統(tǒng)由多個(gè)pac模塊組成戈稿，每個(gè)模塊由pac模塊組成。各pac模塊采用樹(shù)狀結(jié)構(gòu)讶舰，最上層為最基礎(chǔ)模塊鞍盗，逐層組合下上層邏輯。
以下均以政治選舉信息系統(tǒng)為例子介紹（用戶輸入表格跳昼，系統(tǒng)可將數(shù)據(jù)繪制成餅圖般甲，柱狀圖，席位分布圖）鹅颊。
靜態(tài)結(jié)構(gòu)
PAC智能體內(nèi)部結(jié)構(gòu)：
動(dòng)態(tài)圖
情景1 打開(kāi)新的選舉數(shù)據(jù)柱狀圖時(shí)欣除，不同pac智能體之間的協(xié)作，還描述了柱狀圖pac內(nèi)部行為
情景2 描述輸入新數(shù)據(jù)后系統(tǒng)的行為挪略，詳細(xì)說(shuō)明頂層pac智能體的內(nèi)部行為
為了控制器起作用 历帚，這個(gè)getDate 流程有點(diǎn)長(zhǎng)哈滔岳，必然使復(fù)雜度上升
優(yōu)點(diǎn)： 分離關(guān)注點(diǎn) 支持修改和擴(kuò)展 ?支持多任務(wù)（控制線程完成同步控制）
缺點(diǎn)：系統(tǒng)更復(fù)雜 復(fù)雜的控制組件，效率底下
