General Responsibility Assignment
Software Patterns 通用職責分配軟件模式
|
模式名稱
|
描述（問題/解決方案)
|
|
信息專家模式Information Expert
|
問題：對象設計和職責分配的一般原則是什么？
解決方案：將職責分配給擁有履行一個職責所必需信息的類－－即信息專家。（也就是將職責分配給一個類，這個類必須擁有履行這個職責所需要的信息。）
|
|
創建者模式Creator
|
問題：誰應該負責產生類的實例（對應于GoF設計模式系列里的“工廠模式”）
解決方案：如果符合下面的一個或多個條件，則將創建類A實例的職責分配給類B.
.類B聚合類A的對象。
.類B包含類A的對象。
.類B記錄類A對象的實例。
.類B密切使用類A的對象。
.類B初始化數據并在創建類A的實例時傳遞給類A（類B是創建類A實例的一個專家)。
在以上情況下，類B是類A對象的創建者。
|
|
控制器模式
Controller
|
問題：誰處理一個系統事件？
解決方案：當類代表下列一種情況時，為它分配處理系統事件消息的職責。
.代表整個系統、設備或子系統（外觀控制器）。
.代表系統事件發生的用例場景（用例或回話控制器）。
|
|
低耦合Low Coupling
|
問題：如何支持低依賴性以及增加重用性？
解決方案：分配職責時使（不必要的）耦合保持為最低。
|
|
高內聚High Cohesion
|
問題：如何讓復雜性可管理？
解決方案：分配職責時使內聚保持為最高。
|
|
多態模式Polymorphism
|
問題：當行為隨類型變化而變化時誰來負責處理這些變化？
解決方案：當類型變化導致另一個行為或導致行為變化時，應用多態操作將行為的職責分配到引起行為變化的類型。
|
|
純虛構模式Pure Fabrication
|
問題：當不想破壞高內聚和低耦合的設計原則時，誰來負責處理這些變化？
解決方案：將一組高內聚的職責分配給一個虛構的或處理方便的“行為”類，它并不是問題域中的概念，而是虛構的事務，以達到支持高內聚、低耦合和重用的目的。
|
|
中介模式Indirection
|
問題：如何分配職責以避免直接耦合？
解決方案：分配職責給中間對象以協調組件或服務之間的操作，使得它們不直接耦合。
|
|
受保護變化模式Protected Variations
|
問題：如何分配職責給對象、子系統和系統，使得這些元素中的變化或不穩定的點不會對其他元素產生不利影響？
解決方案：找出預計有變化或不穩定的元素，為其創建穩定的“接口”而分配職責。
|
這些更象是一些OOD的原則, 模式會有很多, 但是萬變不離其宗, 大都遵循著一些基本的原則
-
OCP(Open-Closed Principle)
- DIP(Dependency Inversion
Principle)
-
LSP(Liskov Substitution
Principle)
- ISP(Interface Insolation
Principle)
- SRP(Single Resposibility
Principle)
- CARP(Composite/Aggregate Reuse
Principle)
- LoD(Law Of Demeter):don't talk
to stranger
之后我們來詳細討論這些原則