一. 从树谈起 基本上所有人都知道树这个概念。 稍微深究.NET本质的人会懂得,.NET有个对象树。 学习ASP.NET的人肯定会知道,Web上有个控件树。 哪怕是只学习过数据结构应付考试的大学生也会知道Tree这个概念。 二. 把需求扩展成树 举个我们最常用的Photoshop做例子。 在Photoshop中,有许多图形工具,比如星星,比如方形,再比如圆形等等。 在Photoshop中,不用多说,也有很多种颜色供我们选择。 于是就产生了,红色的星星,绿色的星星。红色的方形,绿色的方形等等。 看看所产生的树: |
现在是三种图形,三种颜色,于是我们就一共去声明了九个类,当然我们还不算中间过程中的辅助父类。 如果我们现在是18种图形,12种颜色,那么我们就需要写18*12个类,然后加上12个颜色的类和一个总父类,一共我们需要12*18+12+1=229个类。 让我们记住这个数字。 希望大家不要和我抬杠说,我们可以把颜色写成Color然后动态传入。我们这里是假设并不存在Color这个属性,而需要我们自己去实现。 三. 对象爆炸 这个词我已经在两个设计模式中提到了。 在<重温设计模式(一)——享元模式>中,我就用到了这个词。 当然,这里的爆炸并没有上篇文章中的那么恐怖。 但是追寻完美的我们也应该去改善他。 那就让我们开始想办法。 四. 多继承? 学习C++的我,第一个想到的是多继承。 用多继承描述这个模型再恰当不过了。声明18个图形的类,然后声明12个颜色的类,然后用具体的图形类去多继承。 让我们看看这个表述图: |
错综复杂的线看上去可能有些乱,但是我想大家应该都明白这个意思。 理解倒是容易理解了,可是这个时候我们再来看一下这个类的数量: 颜色12+颜色父类1+图形18+图形父类1+12*18,这个数字似乎比我们之前的那个数字还要大。 也许我会为他辩驳说他牺牲了空间而换取了可读性,但是可怜的C#不支持多继承? 五. 多继承为何被抛弃? 1. 从实际应用讲,B继承A并且重写了方法,C继承A并且重写了方法,那么这个时候D多继承了B和C,那么他究竟是继承B的方法还是C的方法呢? 2. 从面向对象角度讲,每个类只应有一个父类,就像说一个人只能有一个父亲一样。 但是多继承毕竟对我们来说还是比较易用的,他很容易理解,就像段中的颜色和图形一样。 抛弃多继承是从Java开始的,关于历史遗留的多继承问题,他们如何去解决呢? 让我们深入Java阵营内部去探索答案。 六. 深入Java阵营,寻找答案 方法一:用接口来取代继承,这个我不敢兴趣,从前我也知道,我想知道点别的。 方法二:实际上,在我们使用继承时,总有着一个主要继承点和次要继承点。然后我们应该分清主次,然后去继承那个主要继承点,然后用AOP去解决次要继承点的问题。 七. AOP+OOP == Complete OOP AOP,面向切面编程,也称面向方面编程。大多数的设计模式都是在搞接口和外部之间的关系,而很少去深入类的内部去解决问题。AOP则是解决了这个问题。 举个例子,我们在做项目的时候常常需要去记录日志,那么这个日志常常是水平地分布在各个类中,但是其实这个日志功能与这个类的核心功能并无本质联系,这其实违背了对象的单一职责原则,更重要的使这些代码分散个各个角落,非常不容易维护。 AOP其实就是采用一种“横切”技术,深入对象的内部,然后将那些影响了多个类的功能写入一个模块,然后注入到各个类中。从而实现了功能的分离,这个常常用于日志管理,安全控制等次要继承点。 但是我在网上搜了一下,微软官方并未提供AOP框架技术,而都是些子实现框架,尚无Java的Spring之类广泛使用的标准。 八. 退而求其次 Spring的两个关键词:控制反转,依赖注入。 既然我们无法依赖注入,那么我们就普通注入吧。 废话这么多,让我们来步入正题:桥接模式。先来简单地看下结构图: |
讲解之前,让我们先看看桥接模式的意思:将抽象部分与实现部分相分离,使他们都可以相互变化。 九. 代码演化 让我来先讲解一下这个模式的大概思路。 仍然用上面的例子做讲解,按照桥接模式,我们应该把所有可变化的点给抽离出来,然后组合到稳定的部分。先看看代码吧。 class Program { static void Main(string[] args) { PhotoShop ps = new PhotoShop(new RedColor(), |
这个时候的结构图应该是这样的: |
这个时候让我们来计算一下类的总数: 12个颜色类+18个图形类+1个我们的图形=31个类。是不是很少呢? 十. 探微而知著,追本而溯源 世间本没有路,走得人多了,也便成了路。 其实世间本没有模式,只是原则总结了,便成了模式。 模式是可以衍生的,而原则是相对稳定的,那就让我们从这个模式中去挖掘原则。 在文章伊始,我们想到的都是什么?面向对象三原则继承多态封装中的第一个:继承。于是引发了对象爆炸。而用组合,解决了这个问题。 还记得一个很老套的面试题,抽象类和接口的区别。 那就让我们从这个面试题谈起: 1. 接口是行为的契约,而抽象类是特征的抽象。一个是can do,一个是is a。 2. 面向对象设计原则说:组合优于继承。 好了,让我们来看第二点,为什么说组合优于继承,而不说组合取代继承呢? 让我们继续向下看。 十一. 精益求精 组合优于继承,而不是组成取代继承。 上面的代码,如果不仅仅要求颜色和形状,还要求更多,那么我就要写很多很多的属性,好麻烦。 而且更重要的是,如果有这样的需求,我现在有12种颜色,然后有3种形状,分别是方形,圆形和星星,有两种笔,分别是铅笔和蜡笔。但是我现在铅笔只对应方形和星星,蜡笔只对应圆形和星星。也就是说不存在圆形铅笔和方形蜡笔。这样的话我的组合不是浪费了么?而且客户很可能组合错呀? |
是的,不要一味去考虑组合。再重复一次我很爱说的话:模式是为了变化,不要为了模式而模式,我们只需要抽离出变化点就可以了! 如果这样,那我们就写好稳定的部门,有两种选择: |
或者是把颜色的作为父类,这个就是看我们个人的选择了。 这样下来,假设说有很多的类,但是我们只有少数的选择,是不是我们的类更少了呢? 十二. 有一种能力叫做取舍 这句话是我在<Javascript王者归来>上看到的,原文用于HTML在Web标准上的选择遵循上。 这里我想说,桥接模式难并不是难在理解,而是难在应用。难在我们怎么去抽取出这个变化点,而保留住我们稳定点。 这个就是设计人员的取舍能力了! 十三. 举一而反三——工厂还是不工厂 工厂模式,这个我相信大家都在熟悉不过了。 去掉丑陋的if-else,然后用工厂给独立成为类。 应对数据库的变化,用抽象工厂+反射+web.config去搞定不同数据访问层。 应对不同验证方式,用工厂+反射。 这几乎成了Petshop的所有层通用的东西。但是在我们的项目中,真的需要这样么? 首先受if-else,他丑陋在哪里,是因为一旦我们引入了新的逻辑条件,就需要修改源码重新编译。 然后是数据库和验证方式,我想,几乎很少有公司真的去修改数据库和他们所习惯的产品的验证方式。 如果是这样,也就是说这些都是固定的,那么我们还有必要为了模式而模式地去用工厂么? 十四. 桥接总结 |