Bridge模式：就是将抽象和行为分开,分别都有自己的接口和实现类,这样,抽象是不变的,但行为可以任意添加变化,而互相不会影响,比如记日志,日志是接口,有不同的实现:TXT日志,DB日志,行为是怎么记法?在.NET和JAVA平台下有不同的记法,如果再添加一个记法:Other,则不需要修改任何类,这个模式主要是增强程序的可扩展性,降代类之间的耦合
问题:在这个模式中,你曾经说过抽象是不能变化的,我想问一下,即然抽象是不变的,你为什么还要在你的文章中把抽象也定义成了接口,不变,那么我就可以用一个具体类了,请回答一下,谢谢?
>那么我就可以用一个具体类了,请回答一下
可以的，比如模型类就是一个具体类，模型类的持久化动作就是分离的。
这个模式我还有一个问题：只要将抽象和行为分开就行了，而不需要考虑抽象是否要变化，也叫Bridge模式吗？比如，当抽象是一个Log，可以有TxtLog,DocLog等，行为是writeInJava,writeInNet,这个例子中抽象就是变化的（因为可以有不同的Log实现），这样还叫Bridge模式，或者Bridge的重点在哪？谢谢
>Bridge的重点在哪
重点实际是：抽象和行为编码设计时分离；运行时再进行组合。
首先是分离；然后再是合并。
>抽象和行为编码设计时分离；运行时再进行组合
我想对于"运行时再进行组合"这句也是在编码阶段完成的,运行时怎么会自动合并呢,程序怎么知道谁要和谁合并
还有就是:这个模式抽象到底能不能变化,如果能变化,这个变化到底是指什么在变化
>运行时怎么会自动合并呢
当然由客户端组合起来，可以组合多个变化的行为，行为能变，抽象不变。
>行为能变，抽象不变
抽象不变到底是指什么不变,我不太明白,比如,当Log是抽象时,如果在不同情况下,用TXTLOG或DOCLOG实现,这算不算抽象变化??
Log本身一些属性抽象不变，如log的内容等，至于，Log的行为，如以文本形式保存；以Doc形式保存，保存这个行为有不同，可以变化。
你主要区分一下对象中的属性和行为。
将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化.
说下个人见解:上面是GOF标准定义,可以搞清楚这个pattern的目的就是使用弱关联避免强关联(一点不关联,去练隔山打牛,:)),那么第二个问题什么是强关联,什么是弱关联,强关联就是编译期的依赖,其实就是extend继承关系,弱关联就是运行期的关联,其实就是组合/聚合(CRAP),在运行期构建依赖关系.
举个例子,一个抽象类a,它的实现类c要用抽象类b的功能,就把依赖的抽象类b引用进来(在a中引用),而不是继承进来,即c又继承a又继承b(java也不支持多重继承),这样在运行期就可以把b的实现类d注进来,这样避免了编译期的强依赖,灵活一些.
[该贴被litdong于2007年01月25日 15:59修改过]
[该贴被litdong于2007年01月25日 16:13修改过]
[该贴被litdong于2007年01月25日 16:15修改过]
[该贴被litdong于2007年01月25日 16:16修改过]