六大设计原则

在平时设计中，往往忽略的是设计原则，而注重了业务的开发，导致代码质量大大下降，给维护和功能扩展带来了很大的麻烦，设计原则主要涉及以下六种：

1.单一职责原则

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

viewplaincopytoclipboardprint?

publicinterfaceIPhone{

//拨通电话

publicvoiddial(StringphoneNumber);

//通话

publicvoidchat(Objecto);

//通话完毕，挂电话

publicvoidhangup();

}

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

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

2.里氏替换原则

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

主要包含四个部分：

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

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

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

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

viewplaincopytoclipboardprint?

publicclassFather{

publicCollectiondoSometing(HashMapmap){

System.out.println("父类被执行");

returnmap.values();

}

}

publicclasssonextendsFather{

publicCollectiondoSomething(Mapmap){

System.out.println("子类被执行...");

returnmap.values();

}

}

publicclassClient{

publicstaticvoidmain(String[]args){

Fatherf=newFather();

HashMapmap=newHashMap();

f.doSometing(map);

}

}

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

3.依赖倒置原则

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

抽象不应该依赖细节；

细节应该依赖抽象；

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

viewplaincopytoclipboardprint?

//1.构造函数传递依赖对象

publicDriver(ICarcar)

{

this.car=car;

}

//2.setter方法传递依赖对象

publicvoidsetCar(ICarcar)

{

this.car=car;

}

//3.接口申明依赖对象

publicvoiddrive(ICarcar)

{

car.run();

}

4.接口隔离原则

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

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

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

5.迪米特法则

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

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

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

6.开闭原则

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

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

抽象约束；

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

制定项目章程；

封装变化；