设计模式原则

程序猿始终不够
2012-05-16
新浪微博：http://weibo.com/ybchrist


1、“开放-关闭“原则：对修改关闭，对扩展开放

对修改关闭，即原则上我们禁止对已经写好并经过测试，或者已经使用的类进行修改。对于需 求的变化，我们采用扩展的方式对代码进行扩充，而非修改其中的类。

对扩展开放：即允许对已经写好的类进行继承，或者作为部分对象组合成整体对象（组合关系）。

意义：“开放-关闭“原则是面向对象思想的核心，遵守该原则，代码将具有较高的可扩展性和较低耦合。



2、依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象。要针对接口编程，而不是针对实现编程。传递参数，或者在组合聚合关系中，尽量引用层次高的类。

简单的说，就是针对接口编程，而非针对实现的细节问题编程。我们开发软件时，会首先对软件的结构进行分析，之后抽象出高层接口，再层层细化，制定接口规则，再考虑细节实现。



3、里氏代换原则：任何基类可以出现的地方，子类一定可以出现

初看这个原则，似乎很好理解。而实际上，这个原则我们要探究下。

以下引自百度百科：

为了说明，我们先用第一种方法来看一个例子，第二种办法在另外一个原则中说明。我们就看那个著名的长方形和正方形的例子。对于长方形的类，如果它的长宽相等，那么它就是一个正方形，因此，长方形类的对象中有一些正方形的对象。对于一个正方形的类，它的方法有个setSide和getSide，它不是长方形的子类，和长方形也不会符合LSP。
　　eg:
　　长方形类：
　　public class Rectangle{
　　...
　　setWidth(int width){
　　this.width=width;
　　}
　　setHeight(int height){
　　this.height=height
　　}
　　}
　　正方形类：
　　public class Square{
　　...
　　setWidth(int width){
　　this.width=width;
　　this. height=width;
　　}
　　setHeight(int height){
　　this.setWidth(height);
　　}
　　}
　　例子中改变边长的函数：
　　public void resize(Rectangle r){
　　while(r.getHeight()<=r.getWidth){
　　r.setHeight(r.getWidth+1);
　　}
　　}
　　那么，如果让正方形当做是长方形的子类，会出现什么情况呢？我们让正方形从长方形继承，然后在它的内部设置width等于height，这样，只要width或者height被赋值，那么width和height会被同时赋值，这样就保证了正方形类中，width和height总是相等的.现在我们假设有个客户类，其中有个方法，规则是这样的，测试传入的长方形的宽度是否大于高度，如果满足就停止下来，否则就增加宽度的值。现在我们来看，如果传入的是基类长方形，这个运行的很好。根据LSP，我们把基类替换成它的子类，结果应该也是一样的，但是因为正方形类的width和height会同时赋值，这个方法没有结束的时候，条件总是不满足，也就是说，替换成子类后，程序的行为发生了变化，它不满足LSP。
那么我们用第一种方案进行重构，我们构造一个抽象的四边形类，把长方形和正方形共同的行为放到这个四边形类里面，让长方形和正方形都是它的子类，问题就OK了。对于长方形和正方形，取width和height是它们共同的行为，但是给width和height赋值，两者行为不同，因此，这个抽象的四边形的类只有取值方法，没有赋值方法。上面的例子中那个方法只会适用于不同的子类，LSP也就不会被破坏。



4、迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。用面向过程的说法就是减少各个模块（函数）之间的调用关系。

其目的在于降低耦合，是软件更容易扩展与修改。



5、接口隔离法则:这个法则与迪米特法则是相通的,迪米特法则是目的,而接口隔离法则是对迪米特法则的规范。为了做到尽可能小的耦合性,我们需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则。

以上五个原则，每一个都对耦合性的降低提供了很好的解决方法，但同时也让程序中多出了大量的类来支持这五大原则。