设计模式

设计模式
- 前言
- - 设计模式的重要性
  - 设计模式在软件中哪里？
- 正文
- - 1.设计模式的目的
  - 2.设计模式七大原则（设计模式的设计依据，开发人员应该遵循的规则）
  - - 1.单一职责原则 Single Response Principle,SRP
    - 2.接口隔离原则 Interface Segregation Principle,ISP
    - 3.依赖倒置原则 Dependence Inversion Principle,DIP
    - 4.里氏替换原则 Liskov Substitution Priciple,LSP
    - 5.开闭原则 Open Closed Priciple,OCP
    - 6.迪米特法则 Demter Principle,DP
    - 7.合成复用原则 Composite Reuse Principle,CSP
    - 8.七大设计原则的简单总结 Simple Summary

前言

设计模式的重要性

在软件工程中，设计模式是对软件设计中普通存在（反复出现）的各种问题，所提出的解决方案；
可维护性取决于代码的可读性和规范性，如果大家都使用同一的编码规范（设计模式），那么代码的可读性和规范性就会大大提高，从而提高软件的可维护性。

设计模式在软件中哪里？

面向对象（OO）=>功能模块[设计模式+数据结构与算法]=>框架[多种设计模式]=>架构[服务器集群]
OOP思想指导代码风格；功能模块编码过程中，应用到设计模式和数据结构与算法等；框架是由多种设计模式构成的；而框架又构成架构；

正文

1.设计模式的目的

设计模式是为了让程序（软件），具有更好的代码重用性、可读性、可扩展性、可靠性和使程序呈现高内聚，低耦合的特性
代码重用性：相同功能的代码，一次编写，多次使用。
代码可读性：遵循某种编程规范，便于其他开发人员的阅读和理解。
可扩展性：在对现有系统影响最小的情况下，提高系统功能的可持续扩展和提升的能力。
可靠性：当对系统进行功能增加，对原有的系统功能产生最少的影响或没有影响。
高内聚：一个软件模块是由相关性很强的代码组成，只负责一项任务，也就是常说的单一责任原则。
低耦合：模块与模块之间的关联性弱，模块的独立性强

2.设计模式七大原则（设计模式的设计依据，开发人员应该遵循的规则）

我们在使用设计模式的时候要遵循七大原则，分别是:

1.单一职责原则 Single Response Principle,SRP

在类的角度而言，一个类应该只负责一项职责，同时单一职责原则也能应用在方法级别上，道理同上；
e.g. 如class A有两个不同的职责：职责1和职责2；当职责1的需求变更时，那么class A就需要作出改变，而改变A的同时，有可能会导致职责2的执行错误；
所以我们需要将class A分解成两个类：A1,A2,分别单独负责职责1和职责2

以下是实验代码，逐层递进

package demo01.SingleResPrinciple;public class SingleResponsePrinciple {public static void main(String[] args) {Vehicle vehicle = new Vehicle();vehicle.run("三轮车");vehicle.run("小轿车");vehicle.run("单车");}
}
//交通工具类/*** 方案1：* 1.在方案1的run方法中，违反了单一职责原则* 解决方案：根据交通工具运行场景不同，分解成若干个负责单独职责的类*/
class Vehicle{public void run(String vehicle){System.out.println(vehicle+" 在公路上跑....");}
}

方案2：对方案1的改进

package demo01.SingleResPrinciple;public class SingleResponsePrinciple02 {public static void main(String[] args) {SuperVehicle road = new RoadVehicle();road.run("摩托");SuperVehicle sky = new SkyVehicle();sky.run("C919大客机");}
}/*** 方案2：* 1.遵循了单一职责原则* 2.但这种方式改动很大（有时候代价大），即：将类分解，要同时修改C/S两端* 改进方案：直接修改Vehicle类，改变的代码会比较少=>方案3（方法级别上的单一职责原则）*/interface SuperVehicle{public void run(String vehicle);
}
class RoadVehicle implements SuperVehicle{public void run(String vehicle){System.out.println(vehicle+"  在公路上运行");}
}
class SkyVehicle implements SuperVehicle{public void run(String vehicle){System.out.println(vehicle+"  在天上上运行");}
}
class SeaVehicle implements SuperVehicle{public void run(String vehicle){System.out.println(vehicle+"  在海洋中运行");}
}

方案3：在面对系统花销，修改代价上一定程度的妥协（慎用）

package demo01.SingleResPrinciple;public class SingleResponsePrinciple03 {public static void main(String[] args) {Vehicle2 vehicle2 = new Vehicle2();vehicle2.run("摩托");vehicle2.runSky("C919大客机");vehicle2.runSea("铁达呢号");}
}/*** 方案3：* 1.这个方案没有对原来的类作较大的修改，仅新增了方法* 2.这里虽然没有在类级别上颜色遵守单一职责原则；但在方法级别上，遵循了单一职责原则。*/
class Vehicle2{public void run(String vehicle){System.out.println(vehicle +" 在公路上跑");}public void runSky(String vehicle){System.out.println(vehicle+" 在天空飞");}public void runSea(String vehicle){System.out.println(vehicle+" 在海洋航行");}
}

总结：单一职责原则注意事项和细节
1.降低类的复杂度，一个类只负责一个任务（职责）
2.提高类的可读性，可维护性
3.降低需求变更引发的风险
4.通常情况下，我们应当尽量遵循类的单一职责原则；只有在逻辑足够简单，类中方法数量足够少，才能选择在方法级别上遵循单一职责原则（减少系统花销）；否则，请遵守类级别的单一职责原则，将一个类拆分成若干个类，它们分别负责每一个单一职责（任务）；

2.接口隔离原则 Interface Segregation Principle,ISP

概念：一个类对另一个类的依赖，往往是通过接口来实现的。所以一个类对另外一个类的依赖性应当是建立在最小的接口上的。使用多个专门的接口比使用单一的总接口要好。即将一个大的接口拆成若干个小的接口。

让我们在案例中理解
现在我们有这样的需求：类A、类C需要通过接口依赖类B和类D
按照UML图，我们有以下代码

package demo01.Demo02_IntefaceSegraPriciple;public class Segreagion1 {public static void main(String[] args) {//A、C通过接口去依赖B、D//这违反了接口隔离原则，因为A、C只需要一部分的方法；A a = new A();a.depend1(new B());C c = new C();c.depend4(new D());}
}interface  Interface1{void  operation1();void  operation2();void  operation3();void  operation4();void  operation5();}
class B implements Interface1 {public void operation1() {System.out.println("B implements operation1");}public void operation2() {System.out.println("B implements operation2");}public void operation3() {System.out.println("B implements operation3");}public void operation4() {System.out.println("B implements operation4");}public void operation5() {System.out.println("B implements operation5");}
}class D implements  Interface1 {public void operation1() {System.out.println("D implements operation1");}public void operation2() {System.out.println("D implements operation2");}public void operation3() {System.out.println("D implements operation3");}public void operation4() {System.out.println("D implements operation4");}public void operation5() {System.out.println("D implements operation5");}
}class A{//class A通过接口Interface1 依赖（使用）B类，但是只会用到1,2,3方法public void depend1( Interface1 i){//在这，类A对接口依赖存在冗余i.operation1();}public void depend2( Interface1 i){i.operation2();}public void depend3( Interface1 i){i.operation3();}
}
class C{//class C通过接口Interface1 依赖（使用）D类，但是只会用到1,4,5方法public void depend1( Interface1 i){//在这，类C对接口依赖存在冗余i.operation1();}public void depend4( Interface1 i){i.operation4();}public void depend5( Interface1 i){i.operation5();}
}

上述方案1违反了接口隔离原则。虽然最后实现了A、C对B、D的依赖。但是A、C对接口依赖显然存在冗余，在Java编程中，这是不符合规范的，会带来潜在未知的风险。
于是我们有了下面的代码和UML分析图

根据需求和ISP原则，将接口Interface1拆分为独立的几个接口，类A和类C分别与它们所需要的接口建立依赖关系；即采用接口隔离原则
接口Interface1中出现的方法，根据实际情况拆分为三个接口

package demo01.Demo02_IntefaceSegraPriciple.improve;//此案例遵循了接口隔离原则
public class Segreagion2 {public static void main(String[] args) {A a = new A();a.depend1(new B());a.depend2(new B());a.depend3(new B());C c = new C();c.depend1(new D());c.depend4(new D());c.depend5(new D());}
}interface  Interface1{void  operation1();
}
interface  Interface2{void  operation2();void  operation3();
}
interface  Interface3{void  operation4();void  operation5();
}class B implements Interface1,Interface2{public void operation1() {System.out.println("B implements operation1");}public void operation2() {System.out.println("B implements operation2");}public void operation3() {System.out.println("B implements operation3");}}class D implements Interface1,Interface3{public void operation1() {System.out.println("D implements operation1");}public void operation4() {System.out.println("D implements operation4");}public void operation5() {System.out.println("D implements operation5");}
}class A{//class A通过接口Interface1,Interface2 依赖（使用）B类，方法1,2,3都在；不多不少刚刚好public void depend1(Interface1 i){i.operation1();}public void depend2(Interface2 i){i.operation2();}public void depend3(Interface2 i){i.operation3();}
}class C{//class C通过接口Interface1,Interface3 依赖（使用）D类，方法1,4,5都有；不多不少刚刚好public void depend1(Interface1 i){i.operation1();}public void depend4(Interface3 i){i.operation4();}public void depend5(Interface3 i){i.operation5();}
}

3.依赖倒置原则 Dependence Inversion Principle,DIP

1.高层模块不应该依赖底层模块，二者都应该依赖其抽象
2.抽象不应该依赖细节，细节应该依赖抽象（具体类（方法）要依赖接口）
3.依赖倒置的中心思想是面向接口编程
4.依赖倒置原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。
以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。
在java中，抽象指的是接口或抽象类，细节就是具体的实现。
5.使用接口或抽象类的目的是指定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

下面我们用案例来描述：

package demo01.Demo03_Iversion;public class DependecyInversion {public static void main(String[] args) {Person person = new Person();person.receive(new Email());}
}class Email{public String getInfo(){return "电子邮件信息：hello,world";}
}
//完成person接收消息的功能
/*** 方式1分析* 1.简单，比较容易想到* 2.如果我们获取的对象是 微信，短信等，则新增类，同时Person也要增加相应的接收方法，这样扩展性差* 3.解决思路：引入一个抽象的接口IReceiver,表示接收者，这样Person类与接口发生依赖* 因为Email，Wechat 等等都属于接收的范畴，他们各自实现IReceiver就ok了，这样就符合依赖倒置原则*/
class Person{public void receive(Email email){//这里是直接依赖具体细节（具体类）System.out.println(email.getInfo());}
}

通过方案1我们可以看到，有明显的依赖细节，不符合依赖倒置原则；于是有了方案2

package demo01.Demo03_Iversion.improve;public class DependecyInversion {public static void main(String[] args) {//客户端无需改变Person person = new Person();person.receive(new Email());person.receive(new Wechat());}
}//定义接口
interface IReceiver{public String getInfo();
}
class Email implements IReceiver{public String getInfo(){return "电子邮件信息：hello,world";}
}
class Wechat implements IReceiver{public String getInfo(){return "微信信息：hello,world";}
}
//完成person接收消息的功能
class Person{public void receive(IReceiver receiver){//这里我们是对接口实现依赖System.out.println(receiver.getInfo());}
}

在依赖倒置时，往往会发生依赖关系传递，依赖关系传递有主要有三种方式
1.构造器
2.接口
3.setter方法
以下是实验代码

package demo01.Demo03_Iversion.improve;//依赖关系传递的三种方式
public class DependecyInversion2 {public static void main(String[] args) {}
}/*** 方式1.通过接口传递依赖* 开关的接口*/
//interface IOpenAndClose{//    public void open(ITV tv);//抽象方法，接收接口
//}
//interface  ITV{//ITV接口
//    public void play();
//}
实现接口
//class OpenAndClose implements IOpenAndClose{//    public void open(ITV tv) {//        tv.play();
//    }
//}/*** 方式2：通过构造方法传递依赖*/
//interface IOpenAndClode{//    public void open();//抽象方法
//}
//interface ITV{//    public void play();
//}
//class OpenAndClose implements IOpenAndClode{//    public ITV tv;//成员
//    public OpenAndClose(ITV tv){//通过构造器传递参数
//        this.tv=tv;
//    }
//    public void open() {//        this.tv.play();
//    }
//}/*** 方式3.通过setter方传递依赖*/
interface IOpenAndClode{public void open();//抽象方法public void setTV(ITV tv);
}
interface ITV{//ITV接口public void play();
}
class OpenAndClose implements IOpenAndClode{public ITV tv;//成员public void setTV(ITV tv) {//通过set的方式传递依赖this.tv=tv;}public void open() {this.tv.play();}
}

4.里氏替换原则 Liskov Substitution Priciple,LSP

LSP告诉我们继承要遵循的规则
继承的利弊：
1.继承包含这样的一层含义：父类凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类都必须遵循这些契约，
但是如果子类对这些已经实现的方法任意进行任意修改，可能会对整个继承体系造成破坏。
2.继承在给程序带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低；如果一个类被其他的类所继承，
当这个类需要修改的时候，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能发生故障

里氏原则：
1.如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的程序P在所有的对象o1都代换成o2是，程序的行为都没有发生变化。
那么类型T2就是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象
2.在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法
3.里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合、组合、依赖来解决问题。

以下是实验代码
方案1

package demo01.demo04_Liskvo;public class Liskvo {public static void main(String[] args) {A a = new A();System.out.println("11 -3 = "+a.func1(11,3));B b = new B();System.out.println("11-3 = "+b.func1(11,3));}
}
//A类
class A{public int func1(int n1,int n2){return n1-n2;}
}//B类继承了A
//增加了一个新功能：完成两个数相加，然后和9求和
class B extends A{//这里，重写了A类的方法，可能是无意识的public int func1(int n1,int n2){return n1+n2;}public int func2(int n1,int n2){return func1(n1,n2)+9;}
}

方案2.
里氏替换原则告诉我们：原来的原来和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代继承。

package demo01.demo04_Liskvo.improve;/*里氏替换原则告诉我们：原来的福来和子类都继承一个更通俗的基类，原有的继承关系去掉，采用依赖、聚合、组合等关系替代继承。*/public class Liskvo {public static void main(String[] args) {A a = new A();System.out.println("11 -3 = "+a.func1(11,3));B b = new B();//因为B类不再继承A类，因此调用者不会再认为func1是求减法了//调用完成的功能就会很明确System.out.println("10+3 = "+b.func1(10,3));//通过组合仍然可以使用到A类的相关方法System.out.println("11-3 = "+b.func3(11,3));}
}//创建一个更加基础的基类
class Base{//把更加基础的方法和成员写到Base类中}//A类继承Base
class A extends  Base{public int func1(int n1,int n2){return n1-n2;}
}//B类也继承Base
//增加了一个新功能：完成两个数相加，然后和9求和
class B extends  Base {//如果B需要使用A类的方法，使用组合关系private A a =new A();//这里是组合关系public int func1(int n1,int n2){return n1+n2;}public int func2(int n1,int n2){return func1(n1,n2)+9;}//我们仍然想使用A的方法public int func3(int n1,int n2){return this.a.func1(n1,n2);//这里通过组合关系使用A类的方法}
}

5.开闭原则 Open Closed Priciple,OCP

1.OCP是编程中最基础，最重要的设计原则
2.一个软件实体如类，模块和函数应该对扩展开放（对提供方），对修改关闭（使用方）。用抽象构建框架，用实现扩展细节。
3.当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。（只增加代码，不修改代码）
4.编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则。

以下是实验代码

package demo01.demo05_openClosed;
/*** 方案1.* 1.优点是简单明了* 2.缺点了违反了设计原则的ocp原则，即对扩展开放，对修改关闭* 3.比如我们要新增一个图形种类（三角形），需要修改的代码很多*/
public class Ocp {public static void main(String[] args) {//使用看看存在的问题GraphicEditor graphicEditor = new GraphicEditor();graphicEditor.drawShape(new Circle());graphicEditor.drawRectangle(new Rectangle());graphicEditor.drawTriangle(new Triangle());//使用新增的三角形}
}
//这是一个用于绘图的类【使用方】
class GraphicEditor{//接收Shape对象，然后根据type，来绘制不同的图形public void drawShape(Shape s){if (s.m_type ==1)drawRectangle(s);else if(s.m_type==2)drawCircle(s);else if(s.m_type==3)drawTriangle(s);}public void drawRectangle(Shape r){System.out.println(" 矩形 ");}public void drawCircle(Shape r){System.out.println(" 圆形 ");}//新增的绘制三角形public void drawTriangle(Shape r){System.out.println(" 三角形 ");}
}//Shape类，基类
class Shape{int m_type;
}class Rectangle extends  Shape{Rectangle(){super.m_type=1;}
}
class Circle extends Shape{Circle(){super.m_type=2;}
}
//新增的三角形
class Triangle extends Shape{Triangle(){super.m_type=3;}
}

上述代码问题很大，一旦要新增功能，则几乎所有地方都要修改。
以下是改进方案

package demo01.demo05_openClosed.improve;
/**改进方案1的思路：把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承Shape，并实现draw方法即可这样使用方的代码就不用修改了*/
public class Ocp {public static void main(String[] args) {GraphicEditor graphicEditor = new GraphicEditor();graphicEditor.drawShape(new Circle());}
}//这是一个用于绘图的类【使用方】
class GraphicEditor{public void drawShape(Shape s){//接收一个抽象类，细节由子类实现s.draw();}}//Shape类，基类，抽象类
abstract class Shape{int m_type;public void draw(){};
}class Rectangle extends Shape {public void draw(){System.out.println(" 矩形 ");}
}class Circle extends Shape {public void draw(){System.out.println(" 圆形 ");}
}//新增的三角形
class Triangle extends Shape {public void draw(){System.out.println(" 三角形 ");}
}

6.迪米特法则 Demter Principle,DP

1.一个对象应该对其他对象保持最少的了解
2.类与类的关系越密切，耦合度越大
3.迪米特法则(Demter Principle)又叫 最少知道原则 ，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息
4.DP还有一个更简单的定义：只与直接的朋友通信
5.直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象有耦合关系，我们就说着两个对象之间是朋友关系。耦合的方式有很多种：依赖、关联、组合、聚合等。其中我们称出现成员变量、方法参数、方法返回值的类为直接的朋友；而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

总结：
1.DP核心是降低类之间的耦合
2.但是注意：由于每个类都减少了不必要的依赖，因此DP知识要求降低类之间（对象间）耦合度，并不是要求完全没有关系。

用案例来说明DP

以下是实验代码，方案1没有遵循DP

package demo01.demo06_Demter;import java.util.ArrayList;
import java.util.List;//客户端
public class Demter1 {public static void main(String[] args) {//创建一个SchoolManager 对象SchoolManager schoolManager = new SchoolManager();//输出学院的员工id 和 学校总部的员工信息schoolManager.printAllEmployee(new CollegeManager());}
}//学校总部员工类
class Employee{private String id;public String getId() {return id;}public void setId(String id) {this.id = id;}}
//学院的员工
class CollegeEmployee{private String id;public String getId() {return id;}public void setId(String id) {this.id = id;}}//管理学院员工的类
class CollegeManager{//返回学院的所有员工public List<CollegeEmployee> getAllEmployee(){ArrayList<CollegeEmployee> list = new ArrayList<CollegeEmployee>();for (int i = 0; i < 10; i++) {//这里增加了10个员工到list集合CollegeEmployee emp = new CollegeEmployee();emp.setId("学院员工id= "+i);list.add(emp);}return list;}
}
//学校的管理类
/*
* 分析SchoolManager 类的直接朋友有哪些 ？ Employee  ，CollegeManager
*
*
*
* CollegeEmployee 不是直接朋友，而是陌生类，违反了迪米特法则
*
*
* */
class SchoolManager{//返回学校总部的员工public List<Employee> getAllEmployee(){ArrayList<Employee> list = new ArrayList<Employee>();for (int i = 0; i < 5; i++) {//增加了5个员工到list集合Employee emp = new Employee();emp.setId("学校的员工id= "+i);list.add(emp);}return list;}//该方法完成输出学校总部和学院员工信息（id）void printAllEmployee(CollegeManager sub){//分析问题//1.这里的CollegeEmployee 不是 SchoolManager的直接朋友//2.CollegeEmployee 是以局部变量方式出现在 SchoolManager中//获取到学院员工List<CollegeEmployee> list1 = sub.getAllEmployee();System.out.println("------------学院员工------------");for (CollegeEmployee e : list1) {System.out.println(e.getId());}//获取到学校总部员工System.out.println("------------学校总部员工----------------");List<Employee> list2 = this.getAllEmployee();for (Employee e : list2) {System.out.println(e.getId());}}}

以下是改进代码，方案2

package demo01.demo06_Demter.improve;import java.util.ArrayList;
import java.util.List;//客户端
public class Demter1 {public static void main(String[] args) {System.out.println("使用迪米特法则的改进");//创建一个SchoolManager 对象SchoolManager schoolManager = new SchoolManager();//输出学院的员工id 和 学校总部的员工信息schoolManager.printAllEmployee(new CollegeManager());}
}//学校总部员工类
class Employee{private String id;public String getId() {return id;}public void setId(String id) {this.id = id;}}//学院的员工
class CollegeEmployee{private String id;public String getId() {return id;}public void setId(String id) {this.id = id;}}//管理学院员工的类
class CollegeManager{//返回学院的所有员工public List<CollegeEmployee> getAllEmployee(){ArrayList<CollegeEmployee> list = new ArrayList<CollegeEmployee>();for (int i = 0; i < 10; i++) {//这里增加了10个员工到list集合CollegeEmployee emp = new CollegeEmployee();emp.setId("学院员工id= "+i);list.add(emp);}return list;}//输出学院员工的信息public  void printEmployee(){//获取到学院员工List<CollegeEmployee> list1 = this.getAllEmployee();System.out.println("------------学院员工------------");for (CollegeEmployee e : list1) {System.out.println(e.getId());}}
}//学校的管理类
/*
* 分析SchoolManager 类的直接朋友有哪些 ？ Employee  ，CollegeManager
*
*
*
* CollegeEmployee 不是直接朋友，而是陌生类，违反了迪米特法则
*
*
* */
class SchoolManager{//返回学校总部的员工public List<Employee> getAllEmployee(){ArrayList<Employee> list = new ArrayList<Employee>();for (int i = 0; i < 5; i++) {//增加了5个员工到list集合Employee emp = new Employee();emp.setId("学校的员工id= "+i);list.add(emp);}return list;}//该方法完成输出学校总部和学院员工信息（id）void printAllEmployee(CollegeManager sub){//分析问题//1.将输出学院员工的方法，封装到CollegeManager中sub.printEmployee();//获取到学校总部员工System.out.println("------------学校总部员工----------------");List<Employee> list2 = this.getAllEmployee();for (Employee e : list2) {System.out.println(e.getId());}}}

7.合成复用原则 Composite Reuse Principle,CSP

原则是尽量使用合成/聚合的方式，而不是使用继承。

用图来说明
继承的耦合性太强了，推荐使用其他几种方式来实现调用

8.七大设计原则的简单总结 Simple Summary

1.找出应用中可能需要变化之处，把它们独立起来，不要和那些不需要变化的代码混在一起
2.针对接口编程，而不是针对实现编程
3.为了交互对象之间的松耦合设计而努力

设计模式01-设计模式中的七大原则相关推荐

Java思想进阶之设计模式解析前篇（七大原则）
提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档文章目录前言一.七大原则 1.开闭原则 2.单一职责原则 3.接口隔离原则 4.依赖倒转原则 5.里氏替换原则 6.合成复用原则 ...
设计模式中的七大原则（代码 + 图解）
文中涉及的代码:链接:提取码:tqjq 文章目录设计模式 1. 目的 2. 分类 3. 原则 3.1单一职责原则 3.2 接口隔离原则 3.3 依赖倒转原则 3.4 里氏替换原则 3.5 开闭原则 ...
『设计模式』开发设计的七大原则，我做人还是挺有原则，那些代码呢？
23种设计模式+额外常用设计模式汇总 (持续更新)23种设计模式+额外常用设计模式汇总 (持续更新) 设计模式的七大原则: 单一职责原则SRP(Single Responsibility Princi ...
《盘点软件设计中的七大原则》
说在前头:本人为大二在读学生,书写文章的目的是为了对自己掌握的知识和技术进行一定的记录,同时乐于与大家一起分享,因本人资历尚浅,能力有限,文章难免存在一些错漏之处,还请阅读此文章的大牛们见谅与斧正.若 ...
23种设计模式——软件设计模式概述
文章目录 23种设计模式--软件设计模式概述 1.软件设计模式的产生背景 2.软件设计模式的概念与意义 2.1. 软件设计模式的概念 2.2. 学习设计模式的意义 3.软件设计模式的基本要素 4.23 ...
【设计模式系列】之OO面向对象设计七大原则
1 概述本章叙述面向向对象设计的七大原则,七大原则分为:单一职责原则.开闭原则.里氏替换原则.依赖倒置原则.接口隔离原则.合成/聚合复用原则.迪米特法则. 2 七大OO面向对象设计 2.1 单一 ...
大白话设计模式七大原则
开足码力,码动人生,微信搜索[ 程序员大帝 ],关注这个一言不合就开车的的代码界老司机本文 GitHub上已经收录 https://github.com/BeKingCoding/JavaKing ...
设计模式七大原则(C++描述)
前言最近在学习一些基本的设计模式,发现很多博客都是写了六个原则,但我认为有7个原则,并且我认为在编码中思想还是挺重要,所以写下一篇博客来总结下之后有机会会写下一些设计模式的博客(咕咕咕...... ...
JavaScript 设计模式的七大原则（未完成）
设计模式(面向对象)有七大设计原则,分别是: 开闭原则:对扩展开放,对修改关闭单一职责原则:每一个类应该专注于做一件事情里氏替换原则:父类存在的地方,子类是可以替换的依赖倒转原则:实现尽量依赖抽 ...

设计模式01-设计模式中的七大原则