设计模式总结二(开放-封闭原则、依赖倒转原则、装饰模式和代理模式)
前言
之前在设计模式总结一中总结了UML类图、简单工厂模式、策略模式和单一职责原则四个知识点,属于《大话设计模式》的前三章。这一次接着之前的进度继续总结,总结第四章到第七章的内容,分别是:第四章的开放-封闭原则、第五章的依赖倒转原则、第六章的装饰模式和第七章的代理模式。
开放-封闭原则
开放-封闭原则是指软件实体(类、模块、函数等)应该可以扩展,但是不能修改。其中对于扩展是开放的,对于更改是封闭的。简单来说,面对需求的更改。最好是通过增加代码就可以解决问题,而不是改动已有的代码。
这要求我们在写代码之处,先猜测以后需求改动后,最有可能发生变化的部分,然后通过抽象类来隔离这些变化。但是,要注意的是,不论代码有多么“封闭”,都会存在一些无法对之封闭的变化。所以,在一开始程序员就要想好应该封闭哪些“可能发生变化”的部分。
依赖倒转原则和里氏代换原则
依赖倒转原则是指:高层模块不应该依赖低层模块,高层模块和低层模块都应该依赖于抽象。抽象不应该依赖于细节,而细节应该依赖于抽象。这句话在书本的P40页,“高层模块和低层模块都应该依赖于抽象”中的抽象指抽象类和接口(该书是用java实现的,对于C++来讲就一个抽象类),这就使代码“强内聚、低耦合”。
高层模块依赖低层模块,指的是,项目代码往往会把一些功能细化,每个功能都使用函数或者类给封装起来,这些功能性的函数一般是低层模块。高层模块依赖于低层模块指的是复杂的功能大量使用这些低层模块。这样会引发什么问题呢?例如项目换了数据库,从mysql换成了sql server,链接数据库等的代码会不一致,这使得原来一些使用了这些增删改查等功能(低层模块)的高层模块,这时都无法再使用了。我们该做的是将低层模块依赖于抽象类,然后分别写出使用mysql数据库的基本功能模块和使用sql server数据库的基本功能模块,然后高层模块再调用这些功能时候根据抽象类,用多态来选择因该使用哪个底层功能模块。
接着在本章的5.4节,作者又引申出了“里氏代换原则”:子类必须能替代它的父类。具体来说他的意思是“一个软件实体如果使用的是一个父类的话,那么使用这个父类的子类也一定是适用的,而且无法察觉两者的区别。”也就是说吧父类都换成子类,程序的行为和结果不会发生改变。
装饰模式
我对装饰模式的简单理解是将所需要的功能按照正确的顺序串联起来进行控制。书本在P50页给出的定义是:装饰模式动态的给一个对象添加一些额外的职责,例如就增加功能来讲,装饰模式比生成子类更加灵活。
装饰模式的结构图如下所示:

Component是定义了的一个对象接口,动态的给这些对象添加功能。ConcreteComponent是定义了的一个具体的对象,也可以对这个对象增加一些功能。Decorator是抽象的装饰类,继承于Component。ConcreteDecorator是具体的装饰对象,起到给Component添加职责的功能。
总而言之,装饰模式是为已有对象动态添加共能用的。不使用装饰模式时候,当系统需要新的功能时,需要向旧的类中添加新的代码。有了装饰模式,便不用在主类中增加性的字段、新的方法和新的逻辑。只需要在执行特殊功能逻辑的时候,选择使用即可。
代理模式
代理模式是对其它对象提供一种代理以控制对这个对象的访问。代理模式结构图如下所示:

文中举得例子是代追女朋友的例子,有点过于形象,呵呵呵。创建了一个追求者类Pursuit类来执行各种代理功能,感觉较为简单(也可能是我的错觉哈啊哈哈)。
代理模式一般适用于远程代理、虚拟代理、安全代理和智能指引四个场景。
远程代理指为一个对象在不同地址空间提供局部代表。这样可以隐藏一个对象存在于不同的地址空间的事实。
虚拟代理,根据需要创建开销很大的对象。通过它来放置实例化需要很长时间的的对象。
安全代理,用来控制真实对象访问时的权限。
智能指引,调用真实对象时,代理处理另外一些事。
总结
按时复习,再接再厉!!
更多推荐
所有评论(0)