面向对象设计原则和设计模式

GRASP原则

创建者Creator

谁来创建另一个类的示例?
对于类A和类B,满足下列条件
1.B包含A
2.B记录A
3.B和A关系很密切
4.B拥有A实例化所必需的示例
则应该由B来创建A的实例,其中1、2优先

信息专家Information Expert

为一个对象分配职责的一般原则是什么?
谁具有完成一件事情所必须的信息,就把职责分配给它
步骤:
1.把职责描述清楚
2.设计模型中有没有相关的类能做这件事
3.如果没有,就在领域模型中找

低耦合Low Coupling

如何保证设计方案支持低的依赖性、低的变化影响度、增加可重用性?
耦合:两个子模块之间联系的强度
低耦合与其他原则如信息专家、高内聚必须综合考虑
不能单独考虑低耦合
继承关系中,子类和父类的耦合非常紧密(能用组合就不用继承)

控制器Controller

UI应该把捕捉到的系统操作,发给领域层的哪个对象?
Façade Controller外观控制器:
适用于
相对较小的系统
有限数量的系统操作
在消息处理系统中,不能转发消息到可选的控制器时
Use Case/Session Controller用例控制器/会话控制器:
应用场合
当采用外观控制器会导致高耦合、低内聚时
很多系统时间跨越多个不同的处理过程
概念上容易理解和构建

高内聚High Cohesion

如何使对象功能专注、可理解、可管理,同时又支持低耦合?
分配职责时保持高内聚
内聚:模块内元素之间紧密联系的程度,比如一个类内部的操作之间
高内聚的类:
有较少数量的操作,操作的性质基本一致,不会做太多的事情
如果同类别的工作太多,则会定义新的类分担任务,相互间合作

多态Polymorphism

如何处理依据类型不同而有不同行为的一类需求?
使用动态作为依据类型变化的行为,进行职责分配
不要去测试对象的类型或者条件逻辑,并以此选择相应的行为
即不要使用条件逻辑,而是为不同的类定义相同名字的方法
不同的类实现了相同的接口、或者有一个共同的父类(继承)

纯虚构Pure Fabrication

如果依据信息专家原则获得的解决方案不适合,既不想违反低耦合、高内聚,也不想违反其他的原则,该如何把职责分配给对象?
把高度内聚的职责分配给虚构出来的一个类,这个类在领域模型里没有对应的概念,这种方式在有的场合能起到支持低耦合、高内聚、重用的效果
应用纯虚构原则:
可重用
多数情况下按功能类定义新的类,是一种“功能为中心的”对象
如果功能的相关性比较高的话,满足高内聚

间接Indirection

把职责分配到哪里可以避免两个或者多个对象之间的直接耦合?如何解耦对象以保持较高的可重用性?
把职责分配给一个中介对象,隔离对象与其他构建或者服务,使它们不产生直接耦合

隔离变化Protected Variation

如何设计对象、系统和子系统,使得这些成分里面的变化因素、不稳定因素不会对系统的其余部分造成意想不到的影响?
标识出能够预计的变化点或者不稳定点,职责分配的时候创建一个稳定的接口,把它们与系统的其余部分隔离开来
“隔离可能的变化”是一个设计原则,它鼓励使用一个稳定的接口来封装可以预知的变更点
数据封装、多台、数据-驱动设计、服务查询、配置文件、接口都用到了PV
两种可能的变化点
变化点:在当前系统或者当前需求中已经存在了
演化点:推测的类型变化可能发生在今后,但在当前的需求中不存在

开-闭原则Open-Close Principle(OCP)

软件系统在其生命周期都在发生变化,无论是好的设计还是坏的设计,都面临着这个问题,但好的设计是稳定的
软件系统应当允许功能扩展(开放性),可以扩展行为已满足新的需求
不允许修改原有的代码(关闭性)
应当尝试设计永远不需要修改的模块
系统行为的扩展只需要增加新的代码,不能修改已有的代码
模块不允许修改已有的代码,而这种修改会影响客户端

能用组合的地方,就不用继承

继承的副作用:
打破了封装性
继承的代码是静态/编译时绑定的
客户需要购买整个软件包
父类定义了许多硬性的规定
组合的特点:
没有打破封装性
对象组合是一种多态/运行时绑定
整体与部分之间只有接口边界关联,耦合较低
各部分职责明确

依赖倒置原则The Dependency Inversion Principle(DIP)

高层模块不应当依赖低层模块,两者都依赖抽象
抽象不能依赖细节,细节应当依赖抽象
1.面向接口设计,而不是面向实现设计
面向接口设计的原因:
抽象类/接口修改的概率偏低
抽象概念容纳的范围广,易于扩展/修改
不应当修改抽象的类/接口,符合OCP原则
例外:有些类非常成熟、稳定
2.避免传递性依赖
使用继承机制,消除传递性依赖
3.每当有疑虑时,增加一个间接层
如果设计的类找不到一个满意的解决方案,尝试把职责委派其他一个或者多个类
如果B调用C违法了某些原则,考虑让A承担一下职责,让A来调用C

GOF设计模式

特点:
描述了一个反复出现的问题
描述了核心的解决方案
其他人可以无数次使用这个方案解决类似的问题

你可能感兴趣的:(C++,Object,Oriented)