Bridge模式
四人帮的说法“将抽象部分和它的实现部分分离,使他们可以独立地变化”
理解起来就是,有个模块A,能够把它分割成2个独立的概念,一个是它的抽象部分,一个是它的具体实现部分,这2个部分可以独立的改变。就是说如果有了新的实现算法,抽象部分可以不用感知到这种变化,这也是抽象部分就不需要改变;反过来,抽象部分有了变化,对于实现部分也不用去关心这种变化,从而实现部分也不需要变化。
具体例子来说:
有个模块A用于显示,它可以画正方形Rectangle,也可以画圆Circle;同是画的算法有2套(V1Drawing和V2Drawing),最简单的实现模型如下:
基类 Shape,包含一个draw()的方法,从Shape中继承出来 Rectangle类和 Circle类。由于有2套算法,于是在从 Rectangle类中继承出V1Rectangle类和V2 Rectangle类,同是从Circle类中继承出V1Circle类和V2Circle类。统计起来,2个对象,2套算法,一共有4个具体类。如果对象有变化了,还要添加一个五角星的显示,那么3个对象,2套算法,一共6个具体类。如果又有一套新的算法V3Drawing,。。。。。。。。。。总之,具体类将会变成很多很多。
这时候,Bridge模式有用了。抽象部分和实现部分分离。上面的例子,shape就是抽象部分,算法drawing就是实现部分,如果我们把这2个部分分离:
Shape ---> 继承出 Rectangle类 和 Circle类。
Drawing --->继承出 V1Drawing类和V2Drawing类。
他们如何发生关系呢?使用组合(类设计中也有一条原则,优先使用组合而不是继承),即,Shape类中有个成员变量就是Drawing对象的指针。shape的子类通过调用Drawing对象的draw()方法来实现shape的显示功能。
通过这种改变后,如果shape添加了一个五角星类,drawing完全不用关心。同样的drawing如果有个新的之类V3Drawing类,对于shape也是不用关心。2个部分可以独立的进行变化。这就是Bridge模式。
四人帮的说法“将抽象部分和它的实现部分分离,使他们可以独立地变化”
理解起来就是,有个模块A,能够把它分割成2个独立的概念,一个是它的抽象部分,一个是它的具体实现部分,这2个部分可以独立的改变。就是说如果有了新的实现算法,抽象部分可以不用感知到这种变化,这也是抽象部分就不需要改变;反过来,抽象部分有了变化,对于实现部分也不用去关心这种变化,从而实现部分也不需要变化。
具体例子来说:
有个模块A用于显示,它可以画正方形Rectangle,也可以画圆Circle;同是画的算法有2套(V1Drawing和V2Drawing),最简单的实现模型如下:
基类 Shape,包含一个draw()的方法,从Shape中继承出来 Rectangle类和 Circle类。由于有2套算法,于是在从 Rectangle类中继承出V1Rectangle类和V2 Rectangle类,同是从Circle类中继承出V1Circle类和V2Circle类。统计起来,2个对象,2套算法,一共有4个具体类。如果对象有变化了,还要添加一个五角星的显示,那么3个对象,2套算法,一共6个具体类。如果又有一套新的算法V3Drawing,。。。。。。。。。。总之,具体类将会变成很多很多。
这时候,Bridge模式有用了。抽象部分和实现部分分离。上面的例子,shape就是抽象部分,算法drawing就是实现部分,如果我们把这2个部分分离:
Shape ---> 继承出 Rectangle类 和 Circle类。
Drawing --->继承出 V1Drawing类和V2Drawing类。
他们如何发生关系呢?使用组合(类设计中也有一条原则,优先使用组合而不是继承),即,Shape类中有个成员变量就是Drawing对象的指针。shape的子类通过调用Drawing对象的draw()方法来实现shape的显示功能。
通过这种改变后,如果shape添加了一个五角星类,drawing完全不用关心。同样的drawing如果有个新的之类V3Drawing类,对于shape也是不用关心。2个部分可以独立的进行变化。这就是Bridge模式。