今天我看到这篇文章，觉得应该可以解释你最后的困惑。 http://www.cnblogs.com/sjms/archive/2010/06/18/1760624.html

哈哈不错，收藏。。 慢慢研究

难道楼主搞GIS?

@超级奶崽 因为桥接里abstraction表示的是对现实的抽象 比如 ScrollingWindow BorderedWindow 这属于抽象 而实现表示的是具体使用的底层框架、绘制方式等 比如Win32Window XWindow 这些是依赖计算机软件硬件操作系统等环境的 所以叫实现 而接口的抽象表示的是 对方法的参数、类型返回值等的描述 实现表示的是函数中的具体的代码 算法等。 所以这两处的抽象和实现 完全是不同的意思 只是自然语言比较灵活 导致这里用了同一个词

@winter-cn 可是为啥桥接的abstraction不使用接口来做呢。。。。不太明白啊

@winter-cn [quote]Ivony...： 明白了，如果我没理解错，桥接模式是将对象的实质与行为分离，使得它们可以单独变化。所以桥接模式中的abstraction应该取“概念”这个含义。 所以桥接中的两个相对的词是“抽象”和“实现”。其实如果你看成概念和行为就很好理解了。 而依赖倒置原则中的抽象则是本质的含义。换言之依赖倒置原则中的抽象更贴近于我们对抽象的理解。接口比实现更抽象是因为接口是类型行为的本质，实现不是。即我是干什么的，比我是怎么干的，更接近我的本质。 所以依赖倒置中两个相对的词是“抽象”和“具体”，或者“接口”和“实现”。 最后荼毒一番，大家姑妄听之。依赖倒置原则的成立有一个要命的前提，即在一个系统中，具象的东西的变化可能性远大于抽象的东西的变化。如果这个前提不成立，依赖倒置原则就可以忽略（尽管这个前提在觉大多数情况下是成立的）。[/quote] 嗯。。。。。是酱紫的

[quote]LeonSun： [quote]发条橙子： 一个商家要卖杯子，一定要到卖杯子的工厂去购买(商家的方法)，用钱与合同(传递两个参数)，这两个参数与杯子工厂产生操作，也就是说(对象之间传递信息)，购买到杯子后，杯子的特性和操作，比如可以盛水，可以观赏，就随着杯子这个对象到了商家手里，商家想怎么搞就怎么搞，工厂负责生产，商家获取结果，工厂只管生产，商家不懂生产，只要拿到杯子就行。 和人类社会以及自然界的分工协作一样，工厂是对象之间组合，沟通的一个模式。怎么实现，个人所爱。 如果不用工厂怎么样，也可以啊，将商家和厂家组合起来。形成巨无霸。可如果要重组兼并拆分，甚至改制就麻...[/quote] 商家只有一个目的就是买杯子拿钱，工厂只有一个目的就是做杯子拿钱。 假设我们要达到一个目的，就是把杯子卖给消费者，这个动作。 我们可以有很多种方法去实现，我们可以弄一个小作坊并负责买卖，甚至可以开到消费者的门口把店。这都可以达到目的。但如果机器坏了呢？我是不是要自己维修它？如果消费者不愿意买我杯子了呢？我是不是要更新换代我的工厂？同时改变买的方式？.......当你把卖杯子的动作拆开，会发现它有很多种组合方式，在你能力范围内，你怎么搞都行。你愿意做作坊就作坊，愿意做工厂就工厂，但是，当你把你做好的这个动作系统镶嵌到整个街道系统甚至购买系统时，麻烦就会浮现。如果街道改建怎么办？如果原材厂改签了怎么办？是不是任何一个外部变动都会导致你的改变？那怎么维护呢？ 工厂并没有强迫程序员使用，只是，环境改变了，你会自然去使用工厂模式去思考。也许你已经在你代码中加入了这个工厂模式的思想。只是太注重外在的写法和表现形式。纠结于此。至于实现细节，我个人感觉，当错误和麻烦多的时候，自然会自我提升。 个人建议，楼主不必纠结于这些个模式，集中精力写出完美的代码。模式只是一个思想工具。解决的是"怎么办""如何办"的问题。你揪着它一个劲儿的问"为什么",是得不到想到答案的。

[quote]Ivony...： 明白了，如果我没理解错，桥接模式是将对象的实质与行为分离，使得它们可以单独变化。所以桥接模式中的abstraction应该取“概念”这个含义。 所以桥接中的两个相对的词是“抽象”和“实现”。其实如果你看成概念和行为就很好理解了。 ...... [/quote] 嗯 基本就是这个意思 因为恰好使用了同一个词 所以非常容易搞混

明白了，如果我没理解错，桥接模式是将对象的实质与行为分离，使得它们可以单独变化。所以桥接模式中的abstraction应该取“概念”这个含义。 所以桥接中的两个相对的词是“抽象”和“实现”。其实如果你看成概念和行为就很好理解了。 而依赖倒置原则中的抽象则是本质的含义。换言之依赖倒置原则中的抽象更贴近于我们对抽象的理解。接口比实现更抽象是因为接口是类型行为的本质，实现不是。即我是干什么的，比我是怎么干的，更接近我的本质。 所以依赖倒置中两个相对的词是“抽象”和“具体”，或者“接口”和“实现”。 最后荼毒一番，大家姑妄听之。依赖倒置原则的成立有一个要命的前提，即在一个系统中，具象的东西的变化可能性远大于抽象的东西的变化。如果这个前提不成立，依赖倒置原则就可以忽略（尽管这个前提在觉大多数情况下是成立的）。

[quote]超级奶崽： @winter-cn 何谓 另外的意思 依赖倒置 为 底层逻辑依赖高层逻辑 细节依赖抽象么 针对接口编程 而不是针对实现编程 而 桥接的 依赖和实现 不也是针对接口 而不是针对实现么 而这里的抽象对应着一个或多个实现 那这两种的 抽象和实现 区别究竟是什么?[/quote] 话说我知道依赖倒置的抽象指的是什么，桥接的不明白，我去找找资料哈。

有点意思，希望看到多一些这样的讨论，解决初学者的迷惑

@winter-cn 何谓 另外的意思 依赖倒置 为 底层逻辑依赖高层逻辑 细节依赖抽象么 针对接口编程 而不是针对实现编程 而 桥接的 依赖和实现 不也是针对接口 而不是针对实现么 而这里的抽象对应着一个或多个实现 那这两种的 抽象和实现 区别究竟是什么?

abstract class OperationBase { public OperationBase(string connectionString); } 这样最好的解释工厂模式的问题

[quote]超级奶崽： 依赖倒置原则说了 要依赖于抽象，而不是依赖于实现 通常将工厂与桥接使用 因为桥接就是使抽象与实现相分离 其实无所谓对错 主要是看你设计出来的产品好不好用，这个好不好用有很多方面 拓展性啊 容错性啊 之类的。。。。。[/quote] 桥接的"抽象"与"实现"是另外的意思 不要搞混

@Ivony... 其实涉及模式是一种思想 是一种经验 没有环境依赖的 最早的设计模式是一个搞建筑的叫亚历山大的人提出来的。。。。。这种思想能在很多领域上套

依赖倒置原则说了 要依赖于抽象，而不是依赖于实现 通常将工厂与桥接使用 因为桥接就是使抽象与实现相分离 其实无所谓对错 主要是看你设计出来的产品好不好用，这个好不好用有很多方面 拓展性啊 容错性啊 之类的。。。。。

@Ivony... 工厂方法是把Processer设计成一个抽象类 然后由它的子类去决定create哪一个具体类型 即Processer中添加一个virtual createDBConn() = 0; 然后有OracleProcesser和MySQLProcesser去实现createDBConn peace模式没听说过......

[quote]winter-cn： @Ivony... 包装成类型是Command模式......[/quote] 那么工厂方法模式其实就是Command + 简单工厂（或其他工厂）？ 将构造的逻辑从外界传入，在没有委托的情况下，就只能采取多态的方式，如果在Processer内部仅使用这个工厂实例的一个方法，那这个工厂实例从本质上与委托就没有两样。 我对Command模式没有深入的了解，只是大概知道这是一种利用类型来传达信息的模式。如果Command传递的就是行为，那么当这种行为就是new instance的时候，岂不就等价于工厂方法模式？ 事实上，即使是构造逻辑依赖外界而不在内，简单工厂模式同样可用，利用上下文即可，或者我们在创造一种新的模式？ 我从来没有反对过理论和设计模式背后的理念。我所不满的是这种没有节制的造词运动。传统软件行业发展了几十年，沉淀下来的词不过重载、重写、抽象、虚的、多态、泛型等等等等，寥寥可数。而这些专家大牛们动不动就造出了相当于前人几十年造词的总合。 我又粪了，欢迎拍砖。 或者，谈谈对那个什么peace模式的看法吧，我是第一次听说。

@Ivony... 包装成类型是Command模式......

@winter-cn 好吧我该看书了，我竟然没想到工厂方法模式其实是因为那群家伙写设计模式的时候没有委托的存在，从而要将创建对象的方法包装成一个类型的缘故。。。。。 这种行为包装成类型传递的手法，完全可以额外抽象出来描述，所以我真的是很难理解这么多名词的设计模式，看完即忘。