来自：码农翻身（微信号：coderising）
作者：刘欣
令狐冲被师傅岳不群责罚， 来到华山之巅面壁思过，没想到因祸得福， 机缘巧合竟然遇到华山派的前辈风清扬。
风前辈对令狐冲的性情大为欣赏， 决定指点指点他： “如今江湖流行面向对象这门绝技， 你好好修炼一下吧， 看看这本书， 一个月以后来见我。 ”令狐冲孜孜不倦的修习了一个月， 连岳灵珊小师妹都不搭理了。 不但了解了面向对象的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一样“
令狐冲道： “前辈， 我明白了， 这需要努力找出潜在的抽象概念， 非常需要经验和洞察力， 所谓的抽象，就是您说的无招胜有招吧”“是的， 你学会了封装，继承，多态， 也学了设计模式， 但是这些都是具体的招式， 只有学会了抽象，才是应付千变万化的终极招式。 ”令狐冲被折服了， 弯下腰去向着前辈深深的一拜， 等他抬起头， 发现风前辈已经消失了， 风中传来前辈的声音：“不要对任何人提起我......”令狐冲谨记教诲， 等到面壁结束，开始行走江湖，在刀光剑影中不断的积累经验， 磨炼自己的洞察力和抽象能力， 终于成为面向对象设计的一代宗师。 后记：本文的例子其实来自于《敏捷软件开发 原则、模式于实践》， 我加了一点点武侠故事而已， 这是一本非常经典的书，值得每个人仔细研读。
来自：码农翻身（微信号：coderising）
●本文编号2071，以后想阅读这篇文章直接输入2071即可。
●本文分类“软件工程”，搜索分类名可以获得相关文章。
●输入m可以获取到文章目录
Java编程↓↓↓
C/C++编程↓↓↓
更多推荐《15个技术类公众微信》
涵盖：程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。
