专栏名称: 码农翻身

工作15年的前IBM架构师分享好玩有趣的编程知识和职场的经验教训，不容错过。

学习面向对象的令狐冲

码农翻身 · 公众号 · 程序员架构 · 2016-10-20 20:07

正文

令狐冲被师傅岳不群责罚，来到华山之巅面壁思过，没想到因祸得福，机缘巧合竟然遇到华山派的前辈风清扬。

风前辈对令狐冲的性情大为欣赏，决定指点指点他： “如今江湖流行面向对象这门绝技，你好好修炼一下吧，看看这本书，一个月以后来见我。 ”

令狐冲孜孜不倦的修习了一个月，连岳灵珊小师妹都不搭理了。不但了解了面向对象的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，性能优化到开源类库，让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」，技术干货尽在掌握中。