設計模式簡要論述(編輯修改稿)
2025-07-19 18:59 本頁面
【文章內(nèi)容簡介】 持低耦合？解決方案：分配職責以保持較高的內(nèi)聚性。內(nèi)聚性較低的類，要做許多不相關的工作，或需要完成大量的工作。這樣的類是不合理的。這樣的類會有下列問題：l 難以理解l 難以復用l 難以維護l 脆弱，經(jīng)常會受到變化的影響高內(nèi)聚、低耦合是我們進行系統(tǒng)設計時，應該盡量要達到的目標。但是在某些情況下，這些原則也許不太合適。比如在分布式系統(tǒng)的開發(fā)中。分布式系統(tǒng)開發(fā)中的分布式對象之間的互相調(diào)用，可能會跨越網(wǎng)絡，跨網(wǎng)絡調(diào)用會導致系統(tǒng)性能的下降，為了提高性能，所以必須尋找某種手段來降低跨網(wǎng)絡調(diào)用的次數(shù)?？刂破鳎–ontroller）問題：在UI層下首先接收和協(xié)調(diào)（“控制”）系統(tǒng)操作的對象是什么？解決方案：把職責分配給能代表下列選擇之一的對象：l 代表整個“系統(tǒng)”、“根對象”（外觀控制器）。 一般用Fa231。ade模式來實現(xiàn)l 代表發(fā)生系統(tǒng)操作的用例場景（用例控制器）。 如果使用Fa231。ade來實現(xiàn)一個外觀控制器，會使得這個控制器非常臃腫，那么可以考慮采用用例控制器。舉例：比如說，“導入組織機構的數(shù)據(jù)”用例，要求能夠在界面上上傳兩個Excel文件，一個Excel是部門信息，一個Excel是人員信息。那么在實現(xiàn)這個用例的時候，UI層在接收到數(shù)據(jù)之后，應該將業(yè)務邏輯統(tǒng)一交給一個業(yè)務邏輯處理對象來完成。很顯然，這個業(yè)務邏輯對象，需要調(diào)度Excel處理相關的對象、人員信息處理相關的對象、部門信息處理相關的對象等來完成這個導入數(shù)據(jù)的業(yè)務。此業(yè)務邏輯對象就是用例控制器。要注意：MVC中的C，并不是我們這里的控制器。因為MVC中的C處于UI層，而不是業(yè)務邏輯層。多態(tài)（Polymorphism）問題：如何處理基于類型的選擇？如何創(chuàng)建可插拔的軟件構件？解決方案：當相關選擇或行為隨類型（類）有所不同時，使用多態(tài)操作為變化的行為類型分配職責。不要測試對
環(huán)評公示相關推薦
鄂ICP備17016276號-1