设计模式Bridge模式摘要.ppt

桥接模式— Bridge Bridge(桥梁)模式 最初的设计 Bridge(桥梁)模式 需求变化：鸟类要会飞 Bridge(桥梁)模式 如果增加一种鸟类“企鹅”呢？ Bridge(桥梁)模式 改进方法：对“飞”使用多态 Bridge(桥梁)模式 改进方法：再次使用继承 Bridge(桥梁)模式 如果增加“游泳”行为呢？ Bridge(桥梁)模式 继承只会使得问题越来越复杂 继承是面向对象的基本法宝啊？？ OO=类＋对象＋继承＋消息通信 设计原则：组合优先 继承复用的优点 可以很容易的修改或扩展父类的实现 设计原则：组合优先 继承复用的缺点 继承破坏封装，因为父类的实现细节完全暴露给子类(白盒复用) 父类的实现发生改变，则子类必受牵连 继承是静态的，不能在运行时发生改变，不灵活 Bridge(桥梁)模式 是什么导致设计的不完美？ 变化，无法避免的、经常的需求变化 设计者的理想 当需求变化的时候，尽可能少的修改代码就可以满足新的需求 Bridge(桥梁)模式 “发现变化点” Bridge(桥梁)模式 “封装变化点” 变化点1：小鸟一家 Bridge(桥梁)模式 “封装变化点” 变化点2：鸟类的行为——飞 Bridge(桥梁)模式 “封装变化点” 变化点2：鸟类的行为——游泳 Bridge(桥梁)模式 “使变化点和不变点独立开来” 在这个例子里其实是两个变化点相独立 “鸟类”和“行为”什么关系？ 鸟类拥有行为 鸟类行为的具体实现，委托“行为”类来完成 鸟儿拥有飞、游泳的行为 Bridge(桥梁)模式 使用桥梁模式的效果 比如增加一种鸟类“鹅”，相应的要增加一种游泳的行为“红掌拨清波” 只需要增加一个鸟类的子类“鹅” 增加一个游泳的行为“红掌拨清波” 设置“鹅”的飞翔行为为“飞不起来” 设置“鹅”的游泳行为为“红掌拨清波” 原有代码不需要改动！ Bridge(桥梁)模式 Bridge(桥梁)模式 使用桥梁模式的效果 当需求改变的时候（增加动物或行为），只需要简单添加几个类 对原有代码不需要改动 保证了代码的稳定，提高了可维护性 Bridge(桥梁)模式 意图 将抽象部分与它的实现部分分离，使它们都可以独立地变化 适用性 抽象和它的实现部分可以独立变化 类的抽象以及它的实现都可以通过生成子类的方法加以扩充 实现部分的修改不会对客户产生影响 ...... 设计原则：组合优先 组合复用的优点 不破坏封装，这种复用是黑盒复用，因为成员对象的内部细节对新对象保密 所需依赖少(只依赖接口) 是动态的，可以把成员对象动态替换为另一个类型相同的对象 组合复用的缺点 对象数量会增加 使用委托(delegation)会使得系统复杂 设计原则：组合优先 组合优先 Favor composition over inheritance 当需要应对变化的时候，应该首先使用组合的方式，而不是继承 因为组合更加灵活 例1： 汽车有很多种，小轿车、货车、客车，有的车是客货两用，有的车水陆两用 设计原则：组合优先 如果使用继承来描述： 一旦增加新的汽车种类或用途，都需要大量改动原有代码 设计原则：组合优先 使用“组合”思路考虑问题 “汽车”拥有某种或某些“用途” “汽车”和“用途”独立变化，互不影响 设计原则：组合优先 区分“Is-A”与“Has-A” 有一个系统需要描述经理、雇员和学生 它们都是人，所以： 设计原则：组合优先 问题 有些人既是经理，又是学生，比如某位在读MBA的老总 设计原则：组合优先 换一个角度看问题 雇员、经理、学生其实都是角色的一种 人拥有角色 * * 设计原则1：组合优先 优先使用组合，而不是继承 设计原则2：封装可变性 发现代码容易变化的部分，封装之，使它和不容易变化的部分独立开来 设计原则3：开-闭原则 在设计一个软件的时候，应当使这个软件可以在不被修改的前提下扩展