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
1700454448
设计模式之禅 1.4 最佳实践
1700454449
1700454450
阅读到这里,可能有人会问我,你写的是类的设计原则吗?你通篇都在说接口的单一职责,类的单一职责你都违背了呀!呵呵,这个还真是的,我的本意是想把这个原则讲清楚,类的单一职责嘛,这个很简单,但当我回头写的时候,发觉并不是这么回事,翻看了以前的一些设计和代码,基本上拿得出手的类设计都是与单一职责相违背的。静下心来回忆,发觉每一个类这样设计都是有原因的。我查阅了Wikipedia、OODesign等几个网站,专家和我也有类似的经验,基本上类的单一职责都用了类似的一句话来说”This is sometimes hard to see”,这句话翻译过来就是“这个有时候很难说”。是的,类的单一职责确实受非常多因素的制约,纯理论地来讲,这个原则是非常优秀的,但是现实有现实的难处,你必须去考虑项目工期、成本、人员技术水平、硬件情况、网络情况甚至有时候还要考虑政府政策、垄断协议等因素。比如,2004年我就做过一个项目,做加密处理的,甲方就甩过来一句话,你什么都不用管,调用这个API就可以了,不用考虑什么传输协议、异常处理、安全连接等。所以,我们就直接使用了JNI与加密厂商提供的API通信,什么单一职责原则,根本就不用考虑,因为对方不公布通信接口和异常判断。
1700454451
1700454452
对于单一职责原则,我的建议是接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。
1700454453
1700454454
1700454455
1700454456
1700454458
设计模式之禅 第2章 里氏替换原则
1700454459
1700454461
2.1 爱恨纠葛的父子关系
1700454462
1700454463
在面向对象的语言中,继承是必不可少的、非常优秀的语言机制,它有如下优点:
1700454464
1700454465
❑代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性;
1700454466
1700454467
❑提高代码的重用性;
1700454468
1700454469
❑子类可以形似父类,但又异于父类,“龙生龙,凤生凤,老鼠生来会打洞”是说子拥有父的“种”,“世界上没有两片完全相同的叶子”是指明子与父的不同;
1700454470
1700454471
❑提高代码的可扩展性,实现父类的方法就可以“为所欲为”了,君不见很多开源框架的扩展接口都是通过继承父类来完成的;
1700454472
1700454473
❑提高产品或项目的开放性。
1700454474
1700454475
自然界的所有事物都是优点和缺点并存的,即使是鸡蛋,有时候也能挑出骨头来,继承的缺点如下:
1700454476
1700454477
❑继承是侵入性的。只要继承,就必须拥有父类的所有属性和方法;
1700454478
1700454479
❑降低代码的灵活性。子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束;
[
上一页 ]
[ :1.70045443e+09 ]
[
下一页 ]