编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序(软件)具有更好：
设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”
设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么这样设计的依据)。
设计模式常用的七大原则有:
对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。
交通工具案例
方案1
packagecom.atguigu.principle.singleresponsibility;publicclassSingleResponsibility1{ publicstaticvoidmain(String[]args){ Vehiclevehicle=newVehicle(); vehicle.run("摩托车"); vehicle.run("汽车"); vehicle.run("飞机");//(有误)飞机在公路上运行.... }}classVehicle{ publicvoidrun(Stringvehicle){ System.out.println(vehicle+"在公路上运行...."); }}方案2
packagecom.atguigu.principle.singleresponsibility;publicclassSingleResponsibility2{ publicstaticvoidmain(String[]args){ RoadVehicleroadVehicle=newRoadVehicle(); roadVehicle.run("摩托车"); roadVehicle.run("汽车"); AirVehicleairVehicle=newAirVehicle(); airVehicle.run("飞机"); }}classRoadVehicle{ publicvoidrun(Stringvehicle){ System.out.println(vehicle+"公路运行"); }}classAirVehicle{ publicvoidrun(Stringvehicle){ System.out.println(vehicle+"天空运行"); }}classWaterVehicle{ publicvoidrun(Stringvehicle){ System.out.println(vehicle+"水中运行"); }}方案3
packagecom.atguigu.principle.singleresponsibility;publicclassSingleResponsibility3{ publicstaticvoidmain(String[]args){ //TODOAuto-generatedmethodstub Vehicle2vehicle2=newVehicle2(); vehicle2.run("汽车"); vehicle2.runWater("轮船"); vehicle2.runAir("飞机"); }}classVehicle2{ publicvoidrun(Stringvehicle){ System.out.println(vehicle+"在公路上运行...."); } publicvoidrunAir(Stringvehicle){ System.out.println(vehicle+"在天空上运行...."); } publicvoidrunWater(Stringvehicle){ System.out.println(vehicle+"在水中行...."); }}2.3.3单一职责原则注意事项和细节2.4接口隔离原则(InterfaceSegregationPrinciple)2.4.1基本介绍客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。
类图：
packagecom.atguigu.principle.segregation;publicclassSegregation1{
publicstaticvoidmain(String[]args){}}
//接口interfaceInterface1{
voidoperation1();voidoperation2();voidoperation3();voidoperation4();voidoperation5();}
classBimplementsInterface1{
@Overridepublicvoidoperation1(){System.out.println("B实现了operation1");}@Overridepublicvoidoperation2(){System.out.println("B实现了operation2");}@Overridepublicvoidoperation3(){System.out.println("B实现了operation3");}@Overridepublicvoidoperation4(){System.out.println("B实现了operation4");}@Overridepublicvoidoperation5(){System.out.println("B实现了operation5");}}
classDimplementsInterface1{
@Overridepublicvoidoperation1(){System.out.println("D实现了operation1");}@Overridepublicvoidoperation2(){System.out.println("D实现了operation2");}@Overridepublicvoidoperation3(){System.out.println("D实现了operation3");}@Overridepublicvoidoperation4(){System.out.println("D实现了operation4");}@Overridepublicvoidoperation5(){System.out.println("D实现了operation5");}}
classA{//A类通过接口Interface1依赖(使用)B类，但是只会用到1,2,3方法
publicvoiddepend1(Interface1i){i.operation1();}publicvoiddepend2(Interface1i){i.operation2();}publicvoiddepend3(Interface1i){i.operation3();}}
classC{//C类通过接口Interface1依赖(使用)D类，但是只会用到1,4,5方法
publicvoiddepend1(Interface1i){i.operation1();}publicvoiddepend4(Interface1i){i.operation4();}publicvoiddepend5(Interface1i){i.operation5();}}
问题：类A通过接口Interface1依赖类B，类C通过接口Interface1依赖类D，如果接口Interface1对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法。
上述问题解决办法：将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。即采用接口隔离原则。
packagecom.atguigu.principle.segregation.improve;publicclassSegregation1{
publicstaticvoidmain(String[]args){Aa=newA();a.depend1(newB());//A类通过接口去依赖B类a.depend2(newB());a.depend3(newB());Cc=newC();c.depend1(newD());//C类通过接口去依赖(使用)D类c.depend4(newD());c.depend5(newD());}}
//接口1interfaceInterface1{
voidoperation1();}
//接口2interfaceInterface2{
voidoperation2();voidoperation3();}
//接口3interfaceInterface3{
voidoperation4();voidoperation5();}
classBimplementsInterface1,Interface2{
@Overridepublicvoidoperation1(){System.out.println("B实现了operation1");}@Overridepublicvoidoperation2(){System.out.println("B实现了operation2");}@Overridepublicvoidoperation3(){System.out.println("B实现了operation3");}}
classDimplementsInterface1,Interface3{
@Overridepublicvoidoperation1(){System.out.println("D实现了operation1");}@Overridepublicvoidoperation4(){System.out.println("D实现了operation4");}@Overridepublicvoidoperation5(){System.out.println("D实现了operation5");}}
classA{//A类通过接口Interface1,Interface2依赖(使用)B类，但是只会用到1,2,3方法
publicvoiddepend1(Interface1i){i.operation1();}publicvoiddepend2(Interface2i){i.operation2();}publicvoiddepend3(Interface2i){i.operation3();}}
classC{//C类通过接口Interface1,Interface3依赖(使用)D类，但是只会用到1,4,5方法
publicvoiddepend1(Interface1i){i.operation1();}publicvoiddepend4(Interface3i){i.operation4();}publicvoiddepend5(Interface3i){i.operation5();}}
依赖倒转原则(DependenceInversionPrinciple)是指：
请编程完成Person接收消息的功能
实现方案1+分析说明
packagecom.atguigu.principle.inversion;publicclassDependecyInversion{
publicstaticvoidmain(String[]args){Personperson=newPerson();person.receive(newEmail());}}
classEmail{
publicStringgetInfo(){return"电子邮件信息:hello,world";}}
classPerson{
publicvoidreceive(Emailemail){System.out.println(email.getInfo());}}
完成Person接收消息的功能方式1分析
实现方案2+分析说明
packagecom.atguigu.principle.inversion.improve;publicclassDependecyInversion{
publicstaticvoidmain(String[]args){//客户端无需改变Personperson=newPerson();person.receive(newEmail());person.receive(newWeiXin());}}
//定义接口interfaceIReceiver{
publicStringgetInfo();}
classEmailimplementsIReceiver{
@OverridepublicStringgetInfo(){return"电子邮件信息:hello,world";}}
//方式2classPerson{
//这里是对接口的依赖publicvoidreceive(IReceiverreceiver){System.out.println(receiver.getInfo());}}
1、接口传递
应用案例代码
packagecom.atguigu.principle.inversion.improve;publicclassDependencyPass{
publicstaticvoidmain(String[]args){ChangHongchangHong=newChangHong();OpenAndCloseopenAndClose=newOpenAndClose();openAndClose.open(changHong);}}
//方式1：通过接口传递实现依赖//开关的接口interfaceIOpenAndClose{
publicvoidopen(ITVtv);//抽象方法,接收接口}
interfaceITV{//ITV接口
publicvoidplay();}
classChangHongimplementsITV{
@Overridepublicvoidplay(){ //TODOAuto-generatedmethodstub System.out.println("长虹电视机，打开");}}
//实现接口classOpenAndCloseimplementsIOpenAndClose{
@Overridepublicvoidopen(ITVtv){tv.play();}}
2、构造方法传递
publicstaticvoidmain(String[]args){ChangHongchangHong=newChangHong();//通过构造器进行依赖传递OpenAndCloseopenAndClose=newOpenAndClose(changHong);openAndClose.open();}}
//方式2:通过构造方法依赖传递interfaceIOpenAndClose{
publicvoidopen();//抽象方法}
classOpenAndCloseimplementsIOpenAndClose{
publicITVtv;//成员publicOpenAndClose(ITVtv){//构造器this.tv=tv;}@Overridepublicvoidopen(){this.tv.play();}}
@Overridepublicvoidplay(){System.out.println("长虹电视机，打开");}}
3、setter方式传递
publicstaticvoidmain(String[]args){ChangHongchangHong=newChangHong();//通过setter方法进行依赖传递OpenAndCloseopenAndClose=newOpenAndClose();openAndClose.setTv(changHong);openAndClose.open();}}
interfaceIOpenAndClose{
publicvoidopen();//抽象方法publicvoidsetTv(ITVtv);}
privateITVtv;@OverridepublicvoidsetTv(ITVtv){this.tv=tv;}@Overridepublicvoidopen(){this.tv.play();}}
1、继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。
2、继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。
3、问题提出：在编程中，如何正确的使用继承=>里氏替换原则
1、里氏替换原则(LiskovSubstitutionPrinciple)在1988年，由麻省理工学院的Liskov女士提出的。
2、如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。
3、在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。
4、里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。
1、原来运行正常的相减功能发生了错误。原因就是类B无意中重写了父类的方法，造成原有功能出现错误。在实际编程中，常常会通过重写父类的方法完成新的功能，这样写起来虽然简单，但整个继承体系的复用性会比较差。特别是运行多态比较频繁的时候。
2、通用的做法是：原来的父类和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖，聚合，组合等关系代替。
packagecom.atguigu.principle.liskov.improve;publicclassLiskov{
//创建一个更加基础的基类classBase{
//把更加基础的方法和成员写到Base类}
//A类classAextendsBase{
//返回两个数的差publicintfunc1(intnum1,intnum2){ returnnum1-num2;}}
//B类继承了A//增加了一个新功能：完成两个数相加,然后和9求和classBextendsBase{
//如果B需要使用A类的方法,使用组合关系privateAa=newA();//这里，重写了A类的方法,可能是无意识publicintfunc1(inta,intb){ returna+b;}publicintfunc2(inta,intb){ returnfunc1(a,b)+9;}//我们仍然想使用A的方法publicintfunc3(inta,intb){ returnthis.a.func1(a,b);}}
1、开闭原则（OpenClosedPrinciple）是编程中最基础、最重要的设计原则。
2、一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
3、当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。即增加新功能，尽量不修改代码，而是增加代码。
4、编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
看一个画图形的功能。
类图设计，如下:
packagecom.atguigu.principle.ocp;publicclassOcp{
publicstaticvoidmain(String[]args){ //使用看看存在的问题 GraphicEditorgraphicEditor=newGraphicEditor(); graphicEditor.drawShape(newRectangle()); graphicEditor.drawShape(newCircle());}}
//这是一个用于绘图的类[使用方]classGraphicEditor{
//接收Shape对象，然后根据type，来绘制不同的图形publicvoiddrawShape(Shapes){ if(s.m_type==1) drawRectangle(s); elseif(s.m_type==2) drawCircle(s);}//绘制矩形publicvoiddrawRectangle(Shaper){ System.out.println("绘制矩形");}//绘制圆形publicvoiddrawCircle(Shaper){ System.out.println("绘制圆形");}}
//Shape类，基类classShape{
intm_type;}
classRectangleextendsShape{
Rectangle(){ super.m_type=1;}}
classCircleextendsShape{
Circle(){ super.m_type=2;}}
1、优点是简单易操作。
2、缺点是违反了设计模式的ocp原则，即对扩展开放(提供方)，对修改关闭(使用方)。即当给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。
3、比如要新增加一个图形种类三角形，需要做如下修改，修改的地方较多。
代码演示
publicclassOcp{publicstaticvoidmain(String[]args){//使用看看存在的问题GraphicEditorgraphicEditor=newGraphicEditor();graphicEditor.drawShape(newRectangle());graphicEditor.drawShape(newCircle());graphicEditor.drawShape(newTriangle());}}
//接收Shape对象，然后根据type，来绘制不同的图形publicvoiddrawShape(Shapes){if(s.m_type==1){drawRectangle(s);}elseif(s.m_type==2){drawCircle(s);}elseif(s.m_type==3){drawTriangle(s);}}//绘制矩形publicvoiddrawRectangle(Shaper){System.out.println("绘制矩形");}//绘制圆形publicvoiddrawCircle(Shaper){System.out.println("绘制圆形");}//绘制三角形publicvoiddrawTriangle(Shaper){System.out.println("绘制三角形");}}
Rectangle(){super.m_type=1;}}
Circle(){super.m_type=2;}}
//新增画三角形classTriangleextendsShape{
Triangle(){super.m_type=3;}}
使用方于绘图的类GraphicEditor需要修改
思路：把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样当有新的图形种类时，只需要让新的图形类继承Shape，并实现draw方法即可，使用方的代码就不需要修改->满足了开闭原则。
packagecom.atguigu.principle.ocp.improve;publicclassOcp{
publicstaticvoidmain(String[]args){ //使用看看存在的问题 GraphicEditorgraphicEditor=newGraphicEditor(); graphicEditor.drawShape(newRectangle()); graphicEditor.drawShape(newCircle()); graphicEditor.drawShape(newTriangle()); graphicEditor.drawShape(newOtherGraphic());}}
//接收Shape对象，调用draw方法publicvoiddrawShape(Shapes){ s.draw();} }
//Shape类，基类abstractclassShape{
intm_type; publicabstractvoiddraw();//抽象方法}
Rectangle(){ super.m_type=1;}@Overridepublicvoiddraw(){ //TODOAuto-generatedmethodstub System.out.println("绘制矩形");}}
Circle(){ super.m_type=2;}@Overridepublicvoiddraw(){ //TODOAuto-generatedmethodstub System.out.println("绘制圆形");}}
Triangle(){ super.m_type=3;}@Overridepublicvoiddraw(){ //TODOAuto-generatedmethodstub System.out.println("绘制三角形");}}
//新增一个图形classOtherGraphicextendsShape{
OtherGraphic(){ super.m_type=4;}@Overridepublicvoiddraw(){ //TODOAuto-generatedmethodstub System.out.println("绘制其它图形");}}
1、一个对象应该对其他对象保持最少的了解。
2、类与类关系越密切，耦合度越大。
3、迪米特法则(DemeterPrinciple)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息。
4、迪米特法则还有个更简单的定义：只与直接的朋友通信。
5、直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
有一个学校，下属有各个学院和总部，现要求打印出学校总部员工ID和学院员工的id。编程实现上面的功能，看代码演示：
packagecom.atguigu.principle.demeter;importjava.util.ArrayList;importjava.util.List;//客户端publicclassDemeter1{
publicstaticvoidmain(String[]args){ //创建了一个SchoolManager对象 SchoolManagerschoolManager=newSchoolManager(); //输出学院的员工id和学校总部的员工信息 schoolManager.printAllEmployee(newCollegeManager());}}
//学校总部员工类classEmployee{
privateStringid;publicvoidsetId(Stringid){ this.id=id;}publicStringgetId(){ returnid;}}
//学院的员工类classCollegeEmployee{
//管理学院员工的管理类classCollegeManager{
//返回学院的所有员工publicList
//学校管理类
//分析SchoolManager类的直接朋友类有哪些Employee、CollegeManager//CollegeEmployee不是直接朋友而是一个陌生类，这样违背了迪米特法则classSchoolManager{
//返回学校总部的员工publicList
1、前面设计的问题在于SchoolManager中，CollegeEmployee类并不是SchoolManager类的直接朋友(分析)
2、按照迪米特法则，应该避免类中出现这样非直接朋友关系的耦合。
3、对代码按照迪米特法则进行改进。
packagecom.atguigu.principle.demeter.improve;importjava.util.ArrayList;importjava.util.List;//客户端publicclassDemeter1{
publicstaticvoidmain(String[]args){ System.out.println("~~~使用迪米特法则的改进~~~"); //创建了一个SchoolManager对象 SchoolManagerschoolManager=newSchoolManager(); //输出学院的员工id和学校总部的员工信息 schoolManager.printAllEmployee(newCollegeManager());}}
//返回学院的所有员工publicList
//返回学校总部的员工publicList
1、迪米特法则的核心是降低类之间的耦合。
2、但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系，并不是要求完全没有依赖关系。
原则是尽量使用合成/聚合的方式，而不是使用继承。
1、找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。