深入浅出面向对象SOLID原则(3)

[LSP解读]
小Y将其师傅的手艺继承后，但自己又擅自修改了设计风格，结果打造的家具跟袁Sir的期望不一致，这就好比子类替换了父类，产生了不一致的行为，软件不能正常运行，这种继承设计存在潜在的问题。
在软件设计中，LSP 重点强调：对使用者来说，能够使用父类的地方，一定可以使用其子类，并且预期结果是一致的。
简而言之，子类不应该去修改父类已有的功能（在Java中，体现为子类重写了父类中非抽象的方法）。如果你的继承体系中出现了这种替换后不一致的现象，需要警惕你的继承是否合理了。
关于代码示例，请在文末点击阅读文章 让里氏替换原则为你效力[1]
清晰良好的合作协议，让彼此更加信任经过上一次不愉快的合作，袁Sir虽然少挣了一笔钱，还生了一肚子气。但台风来，猪想飞你也挡不住。在房地产彻底疯了的这几年里，袁Sir又捞了好几大桶金。有了钱能做什么呢？当然把公司做大，再挣更多的钱呀。

袁Sir秉着 ‘麻雀虽小，五脏不能不全’ 的原则，成立了财务部、法务部、行政部、人事部、市场部、销售部，由于期初业务量没有大到招架不住，各部门都是光杆司令，而且人事、行政、财务、法务四个部门由小蔡独管（袁Sir流露出了资本家的面貌）。
袁Sir要核对一个报销单，就直接找财务部的小蔡办了，要举办一场年会还得找小蔡，想了解上个月的销售业绩，他去找了销售部的老肖，当然找的最多的还是市场部老史。
经过大半年的快速发展，各部门从光杆司令变成了群狼作战。袁Sir仍然按照之前的方式办事，但遇到了烦恼 – 前天报销单还是小蔡在处理，昨天变成了小吴，今天又换成了小任。当然，其他部门也产生了相同的现象。苦思冥想，袁Sir出了一招：部门的负责人制定一个固定的服务列表，比如财务部小蔡提供服务列表：
核对报销单
处理报销
发工资
招聘新同事
评审绩效
举办年会