结合设计模式说说类的设计

学习设计模式有一段时间了，现想小结一下，说说我对类的设计的一些常用法则的理解。

一，SOLID法则：

Single responsibility principle

每个类仅仅承担一个具体的任务。特别是那些明显不属于类的功能，应该封装到新的类里去。界面和逻辑的分离就是个很好的例子。

Open/Closed principle

软件开发必须考虑可扩展性，但是扩展不能更改现有的代码，否则可能更引起大范围的连锁反应。设计类的时候，可以通过抽象来隔离变化，并通过继承来实现变化。

Liskov substitution principle

如果派生类B公有继承了基类A，即类B是类A的子类型，那么子类型就能够替换掉父类型，而且这种替换关系不可逆。正是这种替换关系使得父类可以被复用。注意并不是所有的"is a"关系都适用里氏代换，比方说：足球和美式足球都叫足球，但是编程的时候，美式足球不能认足球为父类，因为足球只能用脚，而美式足球可以用手。

Interface segregation principle

接口类设计要尽量简练，只需要包含必要的功能即可。比方说：可以简练到只包含一个纯虚函数。

Dependency inversion principle

针对接口编程，而不是针对实现编程。这样使用接口的类就和接口的具体实现分开了，双方都可以灵活自如，只要遵守接口约定即可。实践中纯虚函数就是接口，针对接口编程就是重写纯虚函数。

二，IC法则（为方便记忆我个人取的名字）：

Encapsulation/Information hiding

类的内部数据对外不可见，而只能通过其自身行为改变。封装不仅仅是数据隐藏，也可以是变化点的隐藏。很多设计模式都使用封装来创建接口类，在接口类一侧的修改不会影响到另一侧，从而松开这两侧的耦合，增强了软件的复用。如果被隐藏的具体被调用类报错，只能修改被调用类，而不能在调用类中绕开错误。

Composition

优先使用组合而不是继承。继承是在编译时刻静态定义的，而组合可以在运行时刻动态选择。继承对子类揭示了其父类的实现细节，这就破坏了封装，而组合要求对象遵守共同的接口约定，并不破坏封装。继承中的子类和父类有紧密的依赖关系，而组合由于多了一层接口并不相互依赖。过多的继承可能导致类爆炸，不利于后期的维护，而组合可以防止类爆炸，减少继承层次。

原文链接：http://www.cnblogs.com/xfu123/archive/2012/06/28/2558377.html