1700454419
设计模式之禅 [:1700453905]
1700454420
设计模式之禅 1.3 我单纯，所以我快乐
1700454421
1700454422
对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。所以原则是死的，人是活的，这句话很有道理。
1700454423
1700454424
单一职责原则很难在项目中得到体现，非常难，为什么？在国内，技术人员的地位和话语权都比较低，因此在项目中需要考虑环境，考虑工作量，考虑人员的技术水平，考虑硬件的资源情况，等等，最终妥协的结果是经常违背单一职责原则。而且，我们中华文明就有很多属于混合型的产物，比如筷子，我们可以把筷子当做刀来使用，分割食物；还可以当叉使用，把食物从盘子中移动到口中。而在西方的文化中，刀就是刀，叉就是叉，你去吃西餐的时候这两样肯定都是有的，刀就是切割食物，叉就是固定食物或者移动食物，分工很明晰。这种文化的差异很难一步改造过来，但是我相信随着技术的深入，单一职责原则必然会深入到项目的设计中，而且这个原则是那么的简单，简单得不需要我们更加深入地思考，单从字面上大家都应该知道是什么意思，单一职责嘛！
1700454425
1700454426
单一职责适用于接口、类，同时也适用于方法，什么意思呢？一个方法尽可能做一件事情，比如一个方法修改用户密码，不要把这个方法放到“修改用户信息”方法中，这个方法的颗粒度很粗，比如图1-7中所示的方法。
1700454427
1700454428
1700454429
1700454430
1700454431
图1-7 一个方法承担多个职责
1700454432
1700454433
在IUserManager中定义了一个方法changeUser，根据传递的类型不同，把可变长度参数changeOptions修改到userBO这个对象上，并调用持久层的方法保存到数据库中。在我的项目组中，如果有人写了这样一个方法，我不管他写了多少程序，花了多少工夫，一律重写！原因很简单：方法职责不清晰，不单一，不要让别人猜测这个方法可能是用来处理什么逻辑的。比较好的设计如图1-8所示。
1700454434
1700454435
1700454436
1700454437
1700454438
图1-8 一个方法承担一个职责
1700454439
1700454440
通过上面的类图，如果要修改用户名称，就调用changeUserName方法；要修改家庭地址，就调用changeHomeAddress方法；要修改单位电话，就调用changeOfficeTel方法。每个方法的职责非常清晰明确，不仅开发简单，而且日后的维护也非常容易，大家可以逐渐养成这样的习惯。
1700454441
1700454442
所以，如果对接口、类、方法使用了单一职责原则，那么快乐的就不仅仅是你了，还有你的项目组成员，大家可以轻松而又愉快地进行开发；还有你的老板，减少了因为变更引起的工作量，减少了无谓的人员和资金消耗。当然，最快乐的也许就是你了，因为加官进爵可能等着你哟！
1700454443
1700454444
1700454445
1700454446
1700454447
设计模式之禅 [:1700453906]
1700454448
设计模式之禅 1.4 最佳实践
1700454449
1700454450
阅读到这里，可能有人会问我，你写的是类的设计原则吗？你通篇都在说接口的单一职责，类的单一职责你都违背了呀！呵呵，这个还真是的，我的本意是想把这个原则讲清楚，类的单一职责嘛，这个很简单，但当我回头写的时候，发觉并不是这么回事，翻看了以前的一些设计和代码，基本上拿得出手的类设计都是与单一职责相违背的。静下心来回忆，发觉每一个类这样设计都是有原因的。我查阅了Wikipedia、OODesign等几个网站，专家和我也有类似的经验，基本上类的单一职责都用了类似的一句话来说”This is sometimes hard to see”，这句话翻译过来就是“这个有时候很难说”。是的，类的单一职责确实受非常多因素的制约，纯理论地来讲，这个原则是非常优秀的，但是现实有现实的难处，你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议等因素。比如，2004年我就做过一个项目，做加密处理的，甲方就甩过来一句话，你什么都不用管，调用这个API就可以了，不用考虑什么传输协议、异常处理、安全连接等。所以，我们就直接使用了JNI与加密厂商提供的API通信，什么单一职责原则，根本就不用考虑，因为对方不公布通信接口和异常判断。
1700454451
1700454452
对于单一职责原则，我的建议是接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。
1700454453
1700454454
1700454455
1700454456
1700454457
设计模式之禅 [:1700453907]
1700454458
设计模式之禅 第2章 里氏替换原则
1700454459
1700454460
设计模式之禅 [:1700453908]
1700454461
2.1 爱恨纠葛的父子关系
1700454462
1700454463
在面向对象的语言中，继承是必不可少的、非常优秀的语言机制，它有如下优点：
1700454464
1700454465
❑代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
1700454466
1700454467
❑提高代码的重用性；
1700454468