17.1 罪恶的成绩单
17.1 罪恶的成绩单
“中庸”是中国儒教文化的集中体现,说话或做事情都不能太直接,需要有技巧。比如谈话,如果你要批评某个人,你不能一上来就说他这做得不对,那也做得不对,你要先肯定他的成绩,表扬一下优点;然后再指出不足,指出错误的地方,最后再来点激励,你修改了这些缺点后有哪些好处,比如你能带更多的小兵、升职等。如果你一上来就是一顿批评,你瞅瞅看,对方肯定是不服气,甚至是顶撞你说:“此处不养爷,自有养爷处”,于是甩门而去。
这是说话,做事情也是一样。在山寨产品流行之前,假货也是比较“盛行”的。本人2002 年买了一部手机,当时老板吹得天花乱坠,承诺这部手机是最新的,我看着也像,壳子是崭新的,包装是崭新的,没有任何瑕疵,就是比正品便宜了很多,于是我买了,因为缺钱啊! 用了3个月,坏了,送修检查,结果诊断出这是新壳装旧机,我晕!拿一部旧手机的线路板,找个新的外壳、屏幕、包装就成了新手机,害人不浅啊!
我们不说不开心的事情,今天以什么例子为开场白呢?就说说我上小学的糗事吧。我上小学的时候学习成绩非常差,班级上有40多个同学,我基本上都是排在45名以后,按照老师给我的评价就是:“不是读书的料”。但是我父亲管得很严格,明知道我不是这块料,还是“赶鸭子上架”,每次考完试我都战战兢兢,“竹笋炒肉”是肯定少不了的,但是能少点就少点吧,因为肉可是自己的。四年级期末考试考完,学校出来个很损的招儿(这招儿现在很流行的),打印出成绩单,要家长签字,然后才能上五年级,我那个恐惧呀,不过也就是几秒钟的时间,玩起来什么都忘记了。我们做架构,做设计,任何值得我们回忆的事件都可以通过设计记录下来。当然了,这份成绩单的事情也是可以通过类图表示的,如图17-1所示。
成绩单的抽象类,然后有一个四年级的成绩单实现类,So Easy,我们先来看抽象类, 如代码清单17-1所示。
代码清单17-1 抽象成绩单
1 | public abstract class SchoolReport { |
有抽象类了,我们再来看看具体的四年级成绩单FouthGradeSchoolReport,如代码清单17-2所示。
代码清单17-2 四年级成绩单
1 | public class FouthGradeSchoolReport extends SchoolReport { |
成绩单出来,你别看什么62、65之类的成绩,你要知道,在小学低于90分基本上就是中下等了,悲哀呀,爱学习的人咋就那么多!怎么着,那我把这个成绩单给老爸看看?好,我们修改一下类图,成绩单给老爸看,如图17-2所示。
老爸开始看成绩单,这个成绩单可是最真实的,啥都没有动过,原装,Father类如代码清单17-3所示。
代码清单17-3 老爸查看成绩单
1 | public class Father { |
运行结果如下:
1 | 尊敬的XXX家长: ...... |
就这成绩还要我签字?!老爸就开始找扫帚,我开始做准备:深呼吸,绷紧肌肉,提臀收腹。哈哈,幸运的是,这个不是当时的真实情况,我没有直接把成绩单交给老爸,而是在交给他之前做了点技术工作,我要把成绩单封装一下,封装分类两步来实现,如下所示。
- 汇报最高成绩
跟老爸说各个科目的最高分,语文最高是75,数学是78,自然是80,然后老爸觉得我的成绩与最高分数相差不多,考的还是不错的嘛!这个是实情,但是不知道是什么原因,反正期末考试都考得不怎么样,但是基本上都集中在70分以上,我这60多分基本上还是垫底的角色。
- 汇报排名情况
在老爸看完成绩单后,告诉他我在全班排第38名,这个也是实情,为啥呢?有将近十个同学退学了!这个情况我是不会说的。不知道是不是当时第一次发成绩单时学校没有考虑清楚,没有写上总共有多少同学,排第几名,反正是被我钻了个空子。
那修饰是说完了,我们看看类图如何修改,如图17-3所示。
代码清单17-4 修饰成绩单
1 | public class SugarFouthGradeSchoolReport extends FouthGradeSchoolReport { |
然后对Father类稍做修改就可以看到美化后的成绩单,如代码清单17-5所示。
代码清单17-5 老爸查看修饰后的成绩单
1 | public class Father { |
运行结果如下所示:
1 | 这次考试语文最高是75,数学是78,自然是80 |
通过继承确实能够解决这个问题,老爸看成绩单很开心,然后就给签字了,但现实的情况是很复杂的,可能老爸听我汇报最高成绩后,就直接乐开花了,直接签名了,后面的排名就没必要看了,或者老爸要先看排名情况,那怎么办?继续扩展?你能扩展多少个类?这还是一个比较简单的场景,一旦需要装饰的条件非常多,比如20个,你还通过继承来解决,你想象的子类有多少个?你是不是马上就要崩溃了!
好,你也看到通过继承情况确实出现了问题,类爆炸,类的数量激增,光写这些类不累死你才怪,而且还要想想以后维护怎么办,谁愿意接收这么一大摊本质相似的代码维护工作?并且在面向对象的设计中,如果超过两层继承,你就应该想想是不是出设计问题了,是不是应该重新找一条康庄大道了,这是经验值,不是什么绝对的,继承层次越多以后的维护成本越多,问题这么多,那怎么办?好办,我们定义一批专门负责装饰的类,然后根据实际情况来决定是否需要进行装饰,类图稍做修正,如图17-4所示。
增加一个抽象类和两个实现类,其中Decorator的作用是封装SchoolReport类,如果大家还记得代理模式,那么很容易看懂这个类图,装饰类的作用也就是一个特殊的代理类,真实的执行者还是被代理的角色FouthGradeSchoolReport,如代码清单17-6所示。
代码清单17-6 修饰的抽象类
1 | public abstract class Decorator extends SchoolReport{ |
看到没,装饰类还是把动作的执行委托给需要装饰的对象,Decorator抽象类的目的很简单,就是要让子类来封装SchoolReport的子类,怎么封装?重写report方法!先看HighScoreDecorator实现类,如代码清单17-7所示。
代码清单17-7 最高成绩修饰
1 | public class HighScoreDecorator extends Decorator { |
重写了report方法,先调用具体装饰类的装饰方法reportHighScore,然后再调用具体构件的方法,我们再来看怎么汇报学校排序情况SortDecorator代码,如代码清单17-8所示。
代码清单17-8 排名情况修饰
1 | public class SortDecorator extends Decorator { |
我准备好了这两个强力的修饰工具,然后就“毫不畏惧”地把成绩单交给老爸,看看老爸怎么看成绩单的,如代码清单17-9所示。
代码清单17-9 老爸查看修饰后的成绩单
1 | public class Father { |
老爸一看成绩单,听我这么一说,非常开心,儿子有进步呀,从40多名进步到30多名, 进步很大,躲过了一顿海扁。想想看,如果我还要增加其他的修饰条件,是不是就非常容易了,只要实现Decorator类就可以了!这就是装饰模式。