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
❑降低代码的灵活性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束；
1700454480
1700454481
❑增强了耦合性。当父类的常量、变量和方法被修改时，必需要考虑子类的修改，而且在缺乏规范的环境下，这种修改可能带来非常糟糕的结果——大片的代码需要重构。
1700454482
1700454483
Java使用extends关键字来实现继承，它采用了单一继承的规则，C++则采用了多重继承的规则，一个子类可以继承多个父类。从整体上来看，利大于弊，怎么才能让“利”的因素发挥最大的作用，同时减少“弊”带来的麻烦呢？解决方案是引入里氏替换原则（Liskov Substitution Principle,LSP），什么是里氏替换原则呢？它有两种定义：
1700454484
1700454485
❑第一种定义，也是最正宗的定义：If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.（如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型S是类型T的子类型。）
1700454486
1700454487
❑第二种定义：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.（所有引用基类的地方必须能透明地使用其子类的对象。）
1700454488
1700454489
第二个定义是最清晰明确的，通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。
1700454490
1700454491
1700454492
1700454493
1700454495
设计模式之禅 2.2 纠纷不断，规则压制
1700454496
[
上一页 ]
[ :1.700454447e+09 ]
[
下一页 ]