设计模式笔记之 - Abstract Server & Adapter & Bridge

博客以开关控制灯为例,介绍设计模式的应用。最初设计违反DIP和OCP,引入Abstract Server模式可满足原则。还提到Adapter模式能隔离Light和Switch问题,Bridge模式适用于类型层次多自由度情况,同时指出模式使用应避免不必要的复杂性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

       先看示例,开关控制灯,其中可以使用TurnOnTurnOff,先按照最直接最简单的方法来做,可能得到如下的形式:

abstract_01.gif

很容易发觉,此设计虽然简单,但是它却违反了DIPOCP,因为Switch依赖了具体的类LightDIP告诉我们要优先依赖于抽象类。而如果我们需要扩展此设计,使用Switch管理除Light外其他的类将是比较麻烦的事情。

引入Abstract Server模式,此模式很简单,只需要抽象出接口即可,如下图,可以很容易的使之满足DIPOCP

abstract_02.gif

       需要说明的是接口属于谁,DIP(依赖倒置原则)则给我们指明了方向,接口应该使用者说了算,这里就是应该Switch持有接口,而不是Light。如果要是其他类能被Switch控制,那么只需要继承自Switchable接口即可。

       分析上面的模式,可以发现LightSwitch绑定在一起,要是Light不能改变就麻烦了,这里我们可以引入另外一个模式:Adapter

abstract_03.gif

       可以看到在LightSwitchable之间加多了个适配器来隔离这些问题,Light可以有自己的方法,对应关系完全可以交给LightAdapter来处理,只是要加多一个类了,加了这么多其实都是在需要的时候才加,对大多数情况来说AbstractServer就合适了。

       Bridge模式,在类型层次具有多个自由度的情况中,Bridge模式通常是有用的,我们可以把这些层次结构分开并通过桥把它们结合到一起,而不是把它们合并起来。

       模式既可以带来好处也可以带来坏处,它的坏处就是不必要的复杂性,它应该使用在那些最需要最合适的地方。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

转载于:https://www.cnblogs.com/Dragonpro/archive/2005/09/21/241122.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值