设计模式——六大设计原则

 第一次接触设计模式大概在一年以前，当时了解到的都是一些零散的模式，是配合SSH框架一下看的，不久以后，得到张逸先生对我们设计模式的指导，感触颇深，遗憾的是，我们经验不足，不足以将其很好的用于我们自己的系统中，何况，对目前的我们来说，公司的项目，是不会拿给我们设计的。时间一长，也就忘了，最近感觉该再回过头去看看设计模式了，又恐时间长了，没来得及用，又被遗忘，故采纳了张逸先生给的建议，将其写下来......言归正传，先写写设计模式基础，即六大设计原则：

1.单一职责原则

详细定义：应该有且只有一个原因引起类的变更

public interface IPhone{//拨通电话public void dial(String phoneNumber);//通话public void chat(Object o);//通话完毕，挂电话public void hangup();}

我们在实际的项目中考虑到成本或者时间的问题，像如上代码比比皆是，而且我们也认为i我们应该这样做，但实际上它违背了单一职责原则。为什么呢？它含有两个职责：1.协议管理(拨通电话和挂电话) 2.数据传送(通话)

协议接通的变化会引起其实现类的变化，同时数据传送的变化也会引起实现类的变化，所以从理论上说，本例已经违背了单一职责原则，但是在实际项目开发中我们可以具体情况具体讨论，记住专家说那句话:这个有时候很难说。另外给出的建议是，接口一定要做到单一职责，类的设计尽量做到一个原因引起变化就行

 

2.里氏替换原则

详细定义：只要父类能出现的地方，子类就可以出现

主要包含四个部分：

 

子类必须完全实现父类的方法；

子类可以有自己的个性(因此里氏替换原则可以正着用，却不可以反过来用)；

覆盖或实现父类的方法时输入参数可以被放大；

覆写或实现父类的方法时输出结果可以被缩小；

                           public class Father{public Collection doSometing(HashMap map){ System.out.println("父类被执行"); return map.values(); }}public class son extends Father{public Collection doSomething(Map map){ System.out.println("子类被执行..."); return map.values(); }}public class Client{public static void main(String[]args){ Father f = new Father(); HashMap map =new HashMap(); f.doSometing(map);}}

根据里氏替换原则，此时我们将Father f = new Father()换成Son f =new Son(),其运行结果不会改变。读者可以试试将父类和子类doSomething方法的参数类型换换再试试，就会知道出什么问题

 

3.依赖倒置原则

 

三层含义:高层模块不应依赖底层模块，两者都应该依赖于抽象；

             抽象不应该依赖细节；

             细节应该依赖抽象；

对于该原则，记住一点，面向接口编程。其中依赖的三种写法如下：

//1. 构造函数传递依赖对象public Driver(ICar car){this.car = car;}//2.setter方法传递依赖对象public void setCar(ICar car){this.car = car;}//3.接口申明依赖对象public void drive(ICar car){car.run();}

 

4.接口隔离原则

详细定义：客户端不应该依赖它不需要的接口；类间的依赖关系应该建立在最小的接口上。

需要注意的是，我们在根据接口隔离原则拆分接口时，必须首先满足单一职责原则。

另外再拆分时注意：接口尽量小，接口要高内聚，定制服务(一个模块一个服务)，接口设计粒度要适度

 

5.迪米特法则

详细含义：一个类应该对自己需要耦合或调用的类知道得越少越好。

像诸如getA().getB().getC().getD()形式一定不要出现(JDK API除外)

同时一个类对外公布的接口越少越好

 

6.开闭原则

 

详细含义：对扩展开放，对修改关闭。

主要是为了不影响已有系统的稳定性。从以下几个方面来看：

 

抽象约束；

元数据控制模块行为(用配置文件管理)；

制定项目章程；

封装变化；