查看原文
其他

学习面向对象的令狐冲

2016-10-20 刘欣 码农翻身
令狐冲被师傅岳不群责罚, 来到华山之巅面壁思过,没想到因祸得福, 机缘巧合竟然遇到华山派的前辈风清扬。
风前辈对令狐冲的性情大为欣赏, 决定指点指点他: “如今江湖流行面向对象这门绝技, 你好好修炼一下吧, 看看这本书, 一个月以后来见我。  ”
令狐冲孜孜不倦的修习了一个月, 连岳灵珊小师妹都不搭理了。  不但了解了面向对象的3大特性:封装、继承、多态, 还照着书本敲了好几个例子, 觉得自己已经充分掌握了。
他兴冲冲的去找风前辈: “前辈, 我原来听说面向对象很复杂, 这看过以后也不过如此啊, 你看封装就是为了信息的隐藏, 继承能够做到代码复用, 多态可以让我们对接口编程, 而不是实现编程。 我还知道了Java 对象在内存布局的细节, 这面向对象还有啥啊。”
风前辈说: “你说的是面向对象的一些概念和用法, 皮毛而已, 更难的是面向对象的设计(Object-Oriented Design , 简称OOD)啊”
“OOD?  你给的书里也提到了一些,  不就是找到需求中的名词, 然后建立相关的类, 设置字段属性和方法, 顶多加上继承 ! 这不难吧?”
“你说的只是一些基本的招式,  还不是OOD的精髓, 所以还无法达到无招胜有招的境界。”
“无招胜有招?”
“是的, 一个武功高强的人, 在江湖行走过程中会不断的积累经验, 慢慢的培养出敏锐无比的洞察力, 无论多么复杂困难的形势, 无论对手的招式是啥,武器是啥,  他都能轻松破解, 这就是无招胜有招。” 
令狐冲听得两眼放光, 这简直是顶级的武功秘籍, 一定得学会。
“请前辈赐教!” 

风前辈说:“我给你出个考题, 你先来尝试着用你学的面向对象设计一下。让我想想啊,嗯, 你的师傅岳不群虽然人品不端, 但是经营华山派还算马马虎虎, 除了你们几个师兄弟外, 还雇了不少佣人帮着干活。 咱们就拿这个作为例子来学一下, 听好了!“


“ 你师傅那里有个表格,记录着各种佣人的情况, 佣人主要分为这么几类:1. 正式工,每天都来华山干活,  每个月的最后一天给他们付工钱, 在他们的佣人记录中有个月薪字段。
2. 有些佣人是钟点工, 他们每天提交工作时间卡,其中记录了日期以及工作时辰数,如果每天工作超过6个时辰,按1.5倍进行支付。 每周五发工钱。 每个时辰的报酬也是你师傅定的。
3. 还有一些带薪的佣人,和正式工类似,  会帮助销售咱们华山的土特产, 你师傅根据他们的销售情况,支付给他们一定数量的佣金,他们会提交销售凭条,其中记录了销售的日期和数量, 对这种佣人, 每隔一周的周五发一次工钱。 
这些佣人可以选择支付方式,可以把银票邮寄到他们指定的邮政地址,也可以保存在你师娘那里随时支取,或者要求直接存入他们指定的票号里去。“
令狐冲心里暗想,这有什么难的, 他说: “前辈,给我5分钟,我画个图出来"。
“前辈请看,我设计了四个关键类, 第一个是HourlyEmployee,  代表那些钟点工, 其中记录了每个时辰的报酬(hourlyRate) ; 
第二个是时间卡(TimeCard),  记录了干活的日期和时辰数, 一个钟点工可以有多个TimeCard;
第三个是SalaryEmployee, 他综合了正式工和销售土特产的佣人, 用一个isSales的标志位来区分,  monthSalary 就是每月的固定薪水, commissionRate 是每销售一个土特产的报酬。   第四个类是销售凭条类(SalesReceipt), 记录了销售的日期和数量,  前辈觉得如何? ”
风前辈笑着说: “嗯, 这是一个不错的起点, 你想想你的这些HourlyEmployee和SalaryEmployee是不是有相同的地方? ”
“奥,对,像名称, 地址等应该是相同的, 应该用一下继承,可以搞一个Employee的父类出来, 让HourlyEmployee, SalriedEmployee去继承”
“看起来好一些了, 只是你仔细观察一下SalriedEmployee, 是不是有点乱,  那个commissionRate是 销售一个土特产的佣金, 但是对于正式工根本没有销售佣金的情况, 当你创建一个正式工对象的时候,这个字段就是空值啊, 非常不好, 这违反了单一职责原则。 ,拆分一下吧。”
令狐冲一想,确实是这样, 还有那个isSales 标识其实就在提醒我们,应该拆分成两个类: SalaryEmployee 专门处理每月发薪水的正式工, ComissionEmployee专门处理搞销售的佣人。
风清扬说: “现在考虑下支付的方式吧。 一种是邮寄,一种是直接取, 一种是存入票号。”令狐冲说:“这个简单, 用三个类就可以了”
“那这几个类怎么和刚才的类关联呢?”
令狐冲说:“这个支付方式似乎和佣人的类型没有关系, 因为任何人都可以和选择三种方式之一, 所以不能和HourlyEmployee, SalaryEmployee, ComissionEmployee绑定。  此外肯定不能成为Employee的子类,因为支付方式和佣人之间不存在父子类关系。 ”
令狐冲想了一会, 突然眼前一亮: “应该和Employee绑定啊”
(点击看大图)
风清扬说: ”孺子可教也, 现在重点的部分来了, 你师傅有一天突然决定, 佣人的类型可以来回改变, 一个钟点工可以改成正式工,  正式工可以改成卖土特产的佣人, 卖土特产的也能改成其他两类“ 
“这......  ,  我设计的这个类体系不支持这样的改动啊,我师傅不会这么变态吧” , 令狐冲头上开始冒汗了。
“仔细想想,做一个抽象的时候到了, 一些佣人按时辰获得工钱,一些佣人按月获得工钱,还有一些按销售获得酬金, 这其实暗含着:所有佣人都被支付,只是支付的策略不同
说着风清扬画了一张图:
“看着和刚才的挺像”   风清扬解释道  “其实这里提取出了一个概念:支付策略, 有了这个概念, 就可以和Employee关联,  这样就可以随意的改变佣人的类型了, 你看看这个图, 和刚才你画的那个有啥区别:”
(点击看大图)

令狐冲道: “我明白了, 这是加了一个中间层嘛”


"好了, 你再想想怎么处理发工钱的日期吧。 你师傅说过:有些佣人是钟点工...每周五发工钱 ;  对于月薪的佣人....每个月的最后一天发工钱;  对于佣金的佣人.... 每隔一周的周五发工钱    , 这怎么处理啊? "
令狐冲道: 不就是发钱的日期吗, 可以把他们分别放到SalariedClassifcation, HourlyClassfication, ComissionClassfication中去啊 
“那不就和支付策略绑定了吗?  万一你师傅岳不群说, 这些支付的日期对于不用类型的佣人也可以随意改动怎么办?” 风清扬有点恼怒了。 
看到前辈生气, 令狐冲立刻紧张起来, 心里一动, 立刻明白了 : 这是前辈指点我抽象出一个新的概念了,  叫PaymentDay ?  不好, 还是叫PaymentSchedule吧, 它有三个子类WeeklySchedule, BiWeeklySchdule,MonthlySchedule  , 分别对应每周发工钱, 隔周发工钱, 每月发工钱。 这个新的概念和PaymentMethod, PaymentClassification一样, 都应该和Employee关联, 这样就有了最大的灵活性。 
令狐冲把PaymentSchedule 及其子类放入到了原来的图中, 结果如下:
(点击看大图)


风清扬道: ”现在你明白了吧, 面向对象设计的过程就是一个不断迭代的过程,  很少说是一下子就设计好的 , 在这个过程中要努力的发现变化,并且封装(隔离)变化, 尽可能的从中提取出互相独立的概念出来,就像刚才你做的PaymentMethod, PaymentClassification 和PaymentSchedule一样


令狐冲道: “前辈, 我明白了, 这需要努力找出潜在的抽象概念, 非常需要经验和洞察力, 所谓的抽象,就是您说的无招胜有招吧”
“是的, 你学会了封装,继承,多态, 也学了设计模式,  但是这些都是具体的招式, 只有学会了抽象,才是应付千变万化的终极招式。 ”
令狐冲被折服了, 弯下腰去向着前辈深深的一拜, 等他抬起头, 发现风前辈已经消失了, 风中传来前辈的声音:“不要对任何人提起我......”
令狐冲谨记教诲, 等到面壁结束,开始行走江湖,在刀光剑影中不断的积累经验, 磨炼自己的洞察力和抽象能力,  终于成为面向对象设计的一代宗师。 
后记:本文的例子其实来自于《敏捷软件开发 原则、模式于实践》, 我加了一点点武侠故事而已, 这是一本非常经典的书,值得每个人仔细研读。


你看到的只是冰山一角, 更多精彩文章,尽在“码农翻身” 微信公众号, 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享? 欢迎投稿 ! 我的联系方式:微信:liuxinlehan  QQ: 3340792577
公众号:码农翻身“码农翻身”公众号由工作15年的前IBM架构师创建,分享编程和职场的经验教训。
掘金是一个高质量的技术社区,从 Swift 到 React Native,性能优化到开源类库,让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」,技术干货尽在掌握中。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存