设计模式七大原则

已于 2022-09-09 16:56:31 修改
阅读量145 收藏
点赞数
分类专栏： 设计模式 文章标签： 设计模式 java
于 2022-07-22 20:52:47 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_48468380/article/details/125911374
版权

单一职责原则

基本介绍

一个类只负责一项职责，假如类A负责两个不同的职责：职责1和职责2；当职责1需求变更需要改变A时，可能对职责2的执行造成错误，所以要将类A的粒度分解为2，分别负责两个职责，这样类变更的风险就降低了，同时一个类对应一个职责也有更好的可读性

案例

不符合单一职责的设计

/***
 * @author shaofan
 * @Description 不符合单一职责的设计
 */
public class SingleResponsibility1 {
    public static void main(String[] args) {
        Vehicle motor = new Vehicle("摩托车");
        Vehicle car = new Vehicle("轿车");
        Vehicle plane = new Vehicle("飞机");
        motor.run();
        car.run();
        plane.run();
    }
}

class Vehicle{
    private String name;
    public Vehicle(String name){
        this.name = name;
    }
    public void run(){
        if("飞机".equals(name)){
            System.out.println(name+"在天上飞");
        }else{
            System.out.println(name+"在路上跑");
        }

    }
}

在天上飞行和在地上行驶两个职责被写在了一个类的一个方法中，如果需要添加在水上航行，则需要修改run方法，并且这样的方式代码复杂，可维护性低

严格按照单一职责的设计

/***
 * @author shaofan
 * @Description 严格单一职责划分
 */
public class SingleResponsibility2 {
    public static void main(String[] args) {
        RoadVehicle motor = new RoadVehicle("摩托");
        AirVehicle plane = new AirVehicle("热气球");
        WaterVehicle boat = new WaterVehicle("木船");
        motor.run();
        plane.run();
        boat.run();
    }
}

class RoadVehicle{
    private String name;
    public RoadVehicle(String name){
        this.name = name;
    }
    public void run(){
        System.out.println(name+"在路上跑");
    }
}
class AirVehicle{
    private String name;
    public AirVehicle(String name){
        this.name = name;
    }
    public void run(){
        System.out.println(name+"在天上飞");
    }
}
class WaterVehicle{
    private String name;
    public WaterVehicle(String name){
        this.name = name;
    }
    public void run(){
        System.out.println(name+"在水里游");
    }
}

将不同环境下的行驶放在了不同的类中这样每个类只具有一个职责，但是这样的方式改动较大，会产生较多的类

单一职责简化

class Vehicle2{
    private String name;
    public Vehicle2(String name){
        this.name = name;
    }
    public void runOnRoad(){
        System.out.println(name+"在路上跑");
    }
    public void RunOnAir(){
        System.out.println(name+"在天上飞");
    }
    public void runOnWater(){
        System.out.println(name+"在水里游");
    }
}

这种方式并不是严格遵守单一职责原则的，一个类仍然有多个职责，但是在方法层面遵守了单一职责原则，如果类比较简单易理解，逻辑足够简单，可以使用这种方式

总结

  1. 降低代码的复杂度，一个类只负责一项职责
  2. 提高类的可读性，可维护性
  3. 降低变更引起的风险
  4. 通常情况下，应当严格遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则，如果类中方法数量足够少，可以在方法级别保持单一职责原则，而非类级别

接口隔离原则

基本介绍

客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上；比如某个类没有用到某个接口中的方法，应该依赖作用范围最小的不包含该方法的接口

案例

违背接口隔离原则

interface Interface1{
    void operation1();
    void operation2();
    void operation3();
}

class A implements Interface1{

    @Override
    public void operation1() {
        System.out.println("A1");
    }

    @Override
    public void operation2() {
        System.out.println("A2");
    }

    @Override
    public void operation3() {
        System.out.println("A3");
    }
}

class B implements Interface1{

    @Override
    public void operation1() {
        System.out.println("B1");
    }

    @Override
    public void operation2() {
        System.out.println("B2");
    }

    @Override
    public void operation3() {
        System.out.println("B3");
    }
}

/**
 * C类使用A类，依赖接口Interface1的1，2方法
 */
class C {
    public void operation1(Interface1 i) {
        i.operation1();
    }

    public void operation2(Interface1 i) {
        i.operation2();
    }
}

/**
 * D类使用B类，依赖Interface1的2，3方法
 */
class D {
    public void operation2(Interface1 i) {
        i.operation2();
    }
    public void operation3(Interface1 i) {
        i.operation3();
    }
}

这里只有一个接口Interface1，这个接口有两个实现A和B，类C只使用到了接口的1、2方法；类D只使用到了接口的2、3方法；所以Interface1对类C和类D来说都不是最小接口，都存在冗余的方法，就应该将接口拆分为更小的更小的接口，让类C和类D分别依赖他们需要的最小接口

遵守接口隔离原则

/***
 * @author shaofan
 * @Description 接口隔离原则
 */
public class Segregation2 {
    public static void main(String[] args) {
        C c = new C();
        c.operation1(new A());
        c.operation2(new A());
        
        D d = new D();
        d.operation2(new B());
        d.operation3(new B());
    }
}

interface Interface1{
    void operation1();
}
interface Interface2{
    void operation2();
}
interface Interface3{
    void operation3();
}
class A implements Interface1,Interface2 {

    @Override
    public void operation1() {
        System.out.println("A1");
    }

    @Override
    public void operation2() {
        System.out.println("A2");
    }
}

class B implements Interface2,Interface3{

    @Override
    public void operation2() {
        System.out.println("B2");
    }

    @Override
    public void operation3() {
        System.out.println("B3");
    }
}


class C{
    public void operation1(Interface1 i){
        i.operation1();
    }
    public void operation2(Interface2 i){
        i.operation2();
    }
}

class D{
    public void operation2(Interface2 i){
        i.operation2();
    }
    public void operation3(Interface3 i){
        i.operation3();
    }
}

将Interface拆解成了三个接口，接口1表示C和D都要用到的方法，接口2表示只有C需要用到 的方法，接口3表示只有D需要用到的方；A类和B类实现了自己需要的接口，然后供C类和D类使用

依赖倒转原则

基本介绍

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

案例

违反依赖倒转原则

class Email{
    public String getInfo(){
        return "电子邮件信息";
    }
}

class Person {
    public void receive(Email email){
        System.out.println(email.getInfo());
    }
}

这里person直接依赖于Email类，依赖了细节，这样的代码扩展性低；如果现在需要增加一个接收手机短息消息，那么需要在Person中新加方法，增加了消息接收模块和用户模块的耦合度

遵守依赖倒转原则

interface IReceiver {
    String getInfo();
}

class Email implements IReceiver{

    @Override
    public String getInfo() {
        return "电子邮件";
    }
}

class Person {
    public void receive(IReceiver iReceiver){
        System.out.println(iReceiver.getInfo());
    }
}

使用IReceiver来抽象接收消息这一动作，Person依赖于这个接口，这样需要新增消息类型只用新建一个类来实现这个接口即可，Person模块不需要改动，耦合性降低

总结

  1. 底层模块尽量都要有抽象类和接口，或者两者都有，程序的稳定性更好
  2. 变量的声明类型尽量是抽象类或者接口，这样变量引用和实际对象之间，就存在一个缓冲层，利于程序扩展和优化，当实际对象改变时，调用的模块只要按照规范来写就不用再改
  3. 继承时遵循里氏替换原则

里氏替换原则

继承

  1. 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约（即改方法已经确定细节），虽然它不强制要求所有子类必须遵循这些契约，但是如果子类对这些已经实习的方法任意修改，就会对整个继承体系造成破坏
  2. 继承在给程序设计带来便利的同时，也带来了弊端，比如继承会给程序带来侵入性，可以移植性降低，增加了类之间的耦合度，如果一个类被其他类继承，如果这个类需要修改，必须考虑到所有的子类，并且父类修改后，所有涉及到的子类都有可能产生故障

基本介绍

  1. 如果对每个类型为T1的对象O1，都有类型为T2的对象O2，使得T1定义的所有程序P在所有的对象O1都换成O2时，程序P的行为没有发生变化，那么T2是T1的子类型。即所有使用父类的地方，都必须能够透明的使用其子类的对象， 子类的访问控制修饰符大于父类且子类没有重写父类已经实现的方法
  2. 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类已经实现的方法
  3. 继承实际上让两个类的耦合性增强了，在适当情况下，可以通过聚合、组合、依赖来代替继承解决问题

案例

class A {
    public int func1(int a,int b) {
        return a + b;
    }
    public int func2(int a,int b){
        return a * b;
    }
}

class B extends A{
    @Override
    public int func1(int a, int b){
        return a - b;
    }
}

这里B重写了父类A已经实现的方法，在main函数中就不能将对象a替换成另一个B类型的对象b，因为替换后，func1的实现也发生了变化，违背了里氏替换原则

遵守里氏替换原则

class Base {
    int func1(int a,int b){
        return a+b;
    }
}

class A extends Base{
    public int func2(int a,int b){
        return a-b;
    }
}

class B extends Base{
    private A a;
    public B(A a){
        this.a = a;
    }
    public int func2(int a, int b){
        return this.a.func2(a,b);
    }
}

增加一个更加基础的类，将更加基础的方法放在基类中，而B中如果需要用到A中的方法，使用聚合的方式代替继承，降低耦合度

开闭原则

基本介绍

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

案例

违背开闭原则

/***
 * @author shaofan
 * @Description 违反开闭原则
 */
public class Ocp1 {
    public static void main(String[] args) {
        GraphicEditor editor = new GraphicEditor();
        editor.drawShape(new Circle());
        editor.drawShape(new Rectangle());
    }
}

/***
 * 这是一个绘图的类
 */
class GraphicEditor{
    /**
     * 通过传入的图形类型绘制不同的图形
     * @param shape
     */
    public void drawShape(Shape shape){
        if(shape.type==1){
            drawCircle();
        }else if(shape.type==2){
            drawRectangle();
        }
    }
    private void drawCircle(){
        System.out.println("圆形");
    }
    private void drawRectangle(){
        System.out.println("长方形");
    }
}

/***
 * 图形父类
 */
class Shape{
    int type;
}

/***
 * 圆形
 */
class Circle extends Shape{
    Circle(){
        super.type = 1;
    }
}

/***
 * 矩形
 */
class Rectangle extends Shape{
    Rectangle(){
        super.type=2;
    }
}

这种方式违反了ocp原则，当给类增加新功能的时候，要尽量不修改或少修改已有的代码
假如增加一个需要绘制的三角形，那么需要在GraphicEditor中修改drawShape方法，GraphicEditor就是使用各种Shape对象的使用方，在新增功能的时候，对这里的修改应该关闭

遵守关闭原则

/***
 * 这是一个绘图的类
 */
class GraphicEditor{
    /**
     * 通过传入的图形类型绘制不同的图形
     * @param shape
     */
    public void drawShape(Shape shape){
        shape.draw();
    }
}

/***
 * 图形父类
 */
abstract class Shape{
    int type;
    abstract void draw();
}

/***
 * 圆形
 */
class Circle extends Shape {
    Circle(){
        super.type = 1;
    }

    @Override
    void draw() {
        System.out.println("圆形");
    }
}

/***
 * 矩形
 */
class Rectangle extends Shape {
    Rectangle(){
        super.type=2;
    }
    @Override
    void draw() {
        System.out.println("矩形");
    }
}

将Shape抽象出来，增加一个方法draw，由各个图形子类来实现，这样每个图形类就自己维护自己的绘制方法，绘制逻辑不再由GraphicEditor来实现，GraphicEditor在绘制各个图形时只用调用他们自己的绘制方法即可，同时由于它依赖Shape抽象，遵守了依赖倒转原则，不论新增多少个图形，它都不会改变，新增图形的时候只用按照抽象Shape定义的draw规范来实现对应的方法即可(即对扩展开放)

迪米特法则

基本介绍

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

案例

违背迪米特原则

/***
 * 学校总部的员工类
 */
class Employee{
    private int id;
    public void setId(int id){
        this.id = id;
    }
    public int getId() {
        return this.id;
    }
}

/***
 * 分学院的员工类
 */
class CollegeEmployee{
    private int id;
    public void setId(int id){
        this.id = id;
    }
    public int getId() {
        return this.id;
    }
}

/***
 * 学校总部的管理类
 */
class SchoolManager{
    /**
     * 返回学校总部的所有员工
     * @return
     */
    public List<Employee> getEmployee(){
        List<Employee> employees = new LinkedList<>();
        for (int i = 0; i < 10; i++) {
            Employee employee = new Employee();
            employee.setId(i+1);
            employees.add(employee);
        }
        return employees;
    }

    /**
     * 打印学校和分学院所有的员工
     * @param collegeManager
     */
    public void printAllEmployee(CollegeManager collegeManager){
        System.out.println("学校总部的员工");
        for (Employee employee : getEmployee()) {
            System.out.println(employee.getId());
        }
        System.out.println("学院的员工");
        for (CollegeEmployee employee : collegeManager.getEmployee()) {
            System.out.println(employee.getId());
        }
    }
}

/***
 * 分学院的管理类
 */
class CollegeManager{
    /**
     * 返回分学院的所有员工
     * @return
     */
    public List<CollegeEmployee> getEmployee(){
        List<CollegeEmployee> employees = new LinkedList<>();
        for(int i=0;i<10;i++){
            CollegeEmployee employee = new CollegeEmployee();
            employee.setId(i+1);
            employees.add(employee);
        }
        return employees;
    }
}

SchoolManager的直接朋友有Employee、CollegeManager，没有CollegeEmployee，CollegeEmployee的对象仅仅以局部变量出现在了SchoolManager的方法中；违背了迪米特法则

遵守迪米特原则

/***
 * 学校总部的员工类
 */
class Employee{
    private int id;
    public void setId(int id){
        this.id = id;
    }
    public int getId() {
        return this.id;
    }
}

/***
 * 分学院的员工类
 */
class CollegeEmployee{
    private int id;
    public void setId(int id){
        this.id = id;
    }
    public int getId() {
        return this.id;
    }
}

/***
 * 学校总部的管理类
 */
class SchoolManager{
    /**
     * 返回学校总部的所有员工
     * @return
     */
    public List<Employee> getEmployee(){
        List<Employee> employees = new LinkedList<>();
        for (int i = 0; i < 10; i++) {
            Employee employee = new Employee();
            employee.setId(i+1);
            employees.add(employee);
        }
        return employees;
    }

    /**
     * 打印学校总部的员工
     */
    public void printEmployee(){
        for (Employee employee : getEmployee()) {
            System.out.println(employee.getId());
        }
    }

    /**
     * 打印学校和分学院所有的员工
     * @param collegeManager
     */
    public void printAllEmployee(CollegeManager collegeManager){
        System.out.println("学校总部的员工");
        printEmployee();
        System.out.println("学院的员工");
        collegeManager.printEmployee();
    }
}

/***
 * 分学院的管理类
 */
class CollegeManager{
    /**
     * 返回分学院的所有员工
     * @return
     */
    public List<CollegeEmployee> getEmployee(){
        List<CollegeEmployee> employees = new LinkedList<>();
        for(int i=0;i<10;i++){
            CollegeEmployee employee = new CollegeEmployee();
            employee.setId(i+1);
            employees.add(employee);
        }
        return employees;
    }

    /**
     * 打印分学院的员工
     */
    public void printEmployee(){
        for (CollegeEmployee employee : getEmployee()) {
            System.out.println(employee.getId());
        }
    }
}

CollegeManager和SchoolManager都自己维护自己的打印方法，School在调用的时候只需要使用他们暴露的接口，而不管他们内部的逻辑；即调用方不需要知道他们各自怎么实现打印，只需要调用他们提供的打印接口来打印即可，这样SchoolManager中就没有了CollegeEmployee

总结

  1. 迪米特法则之间的核心是降低类之间的耦合
  2. 但是注意：由于每个类型中减少了不必要的依赖，因此迪米特法则只是要求降低类之间的耦合度，并不是完全消除耦合

合成复用原则

基本介绍

能够使用合成/聚合的关系，就不要使用继承

案例

违背合成复用原则

class A {
    public int operation1(){
        return 1;
    }
    public int operation2(){
        return 1;
    }
}

class B extends A{
    public int operation(){
        return super.operation1()+super.operation2();
    }
}

这里B需要使用到A的方法，而不需要实现A中的方法，使用B继承A的方式来获取A中的方法，这样A和B的耦合度较高

遵守合成复用原则

class A {
    public int operation1(){
        return 1;
    }
    public int operation2(){
        return 1;
    }
}

class B{
    private A a = new A();
    public int operation(){
        return a.operation1()+a.operation2();
    }
}

这里A组合到了B中，而不再是B继承A，这样如果A中添加了某个抽象方法，B也不用管他，降低了耦合度

设计原则核心思想

  1. 找出应用中可能会发生变化的地方，把他们独立出来，不要和那些不需要变化的代码混在一起
  2. 针对接口编程，而不是针对实现编程
  3. 为了互相交互的类之间的松耦合设计而努力
老蛙@
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
设计模式的几大原则
qq_45726327的博客
06-18 2108
设计模式原则，其实就是程序员在编程时，应当遵守的原则， 也是各种设计模式的基础(即： 设计模式为什么这样设计的依据)设计模式常用的六大原则有:①单一职责原则②里氏替换原则③依赖倒转(倒置)原则④接口隔离原则⑤迪米特法则⑥开闭原则什么是单一职责原则呢?
设计模式六大原则
西京刀客
05-13 1万+
文章目录软件设计的六大原则1. 开放-封闭原则2. 单一职责原则举例3. 里氏替换原则4. 依赖倒置原则举例5. 接口隔离原则6. 迪米特原则举例 软件设计的六大原则 设计模式的六大原则 参考URL: https://zhuanlan.zhihu.com/p/92152190 1. 开放-封闭原则 Open-Close Principle（OCP）：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。目的就是保证程序的扩展性好，易于维护和升级。 对于扩展是开放的，对于更改是封闭的。 开放-封闭原则是面向
设计模式之六大原则（转载）
weixin_34126215的博客
09-21 1570
设计模式之六大原则（转载） 　　关于设计模式的六大设计原则的资料网上很多，但是很多地方解释地都太过于笼统化，我也找了很多资料来看，发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂，因此转载过来。 　　原作者博客链接：http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 　　原文链接：http://b...
yoyiyi#SoleilNotes#001.设计模式七大原则1
07-25
2.1 单一职责原则 2.2 接口隔离原则 2.3 依赖倒置原则 2.4 里式替换原则 2.5 开闭原则 2.6 迪米特原则 2.7 合成复用原则
第一章设计模式与七大原则.doc
02-28
设计模式是软件工程中的一种重要思想，它是经验丰富的软件开发者在实践中提炼出来的一套解决方案模板。...在实际开发中，选择合适的设计模式和遵循设计原则，可以帮助我们构建出更加优雅、可扩展的系统。
Java23种设计模式6大原则总结.doc
11-24
设计模式可以分为三大类：创建型模式、结构型模式、行为型模式。 创建型模式的主要功能是封装创建逻辑，使得客户代码尽量不修改或少修改。常见的创建型模式有单例模式、工厂方法模式、抽象工厂模式、建造者模式、...
12-附录 1 设计模式的七大原则(1).html
04-01
在书中，作者们将这二十三种设计模式分成了三类，分别是创建型模式、结构型模式和行为型模式。 创建型模式包含了： 工厂方法模式（ Factory Method ） 抽象工厂模式（ Abstract Factory ） 单例模式（ Singleton ...
24种设计模式介绍与6大设计原则
08-30
二、设计模式的六大原则 1、开闭原则（Open Close Principle） 开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序...
设计模式的7大原则
qq_44065088的博客
08-19 8951
其实不过是什么设计模式，都会尽量的遵循这最为核心的七大原则，那么是哪七大原则呢？ 花了大把时间总结如果 对你有帮助清点赞，白嫖者 三天之内必得痔疮 一.设计模式常用的七大原则有: 1) 单一职责原则 2) 接口隔离原则 3) 依赖倒转(倒置)原则 4) 里氏替换原则 5) 开闭原则 6) 迪米特法则 7) 合成复用原则 诶？这几个是什么意思呢？ 不用怕,我给大家逐一来介绍一下 1.单一职责原则 对类来说的，即一个类应该只负责一项职责。如类A...
设计原则：面向对象设计原则详解
热门推荐
黄规速博客:学如逆水行舟，不进则退
05-17 3万+
我们在应用程序开发中，一般要求尽量两做到可维护性和可复用性。 应用程序的复用可以提高应用程序的开发效率和质量，节约开发成本，恰当的复用还可以改善系统的可维护性。而在面向对象的设计里面，可维护性复用都是以面向对象设计原则为基础的，这些设计原则首先都是复用的原则，遵循这些设计原则可以有效地提高系统的复用性，同时提高系统的可维护性。面向对象设计原则和设计模式也是对系统.........
浅谈设计模式的六大原则
小样
05-26 4415
一，单一职责原则：就一个类而言，应该仅有一个引起它变化的原因（就是实现类要责任单一） 英文--Single Responsibility Principle  简写：SRP 举个例子：    父类：Animal public class Animal { void move(String animal){ System.out.println(animal + "是主要用脚来
设计模式的七大设计原则
weixin_57393819的博客
07-04 605
设计模式就是为了让程序具有更好的 ：即用多个专门的接口,而不是用单一的总接口,客户端不应该依赖它不需要的接口。 因此这个原则需要我们在设计接口时应当注意一下几点 ： 1、一个类对一个类的依赖应该建立在最小的接口之上。 2、建立单一接口,不要建立庞大臃肿的接口。 3、尽量细化接口,接口中的方法尽量少(不是越少越好,一定要适度)。 我们在设计接口的时候,要多花时间去思考,要考虑业务模型,包括以后有可能发生变更的地方还要做一些预判。即 :即 ：即 ：即 ：即 ：其实在实际开发过程中,并不是一定要求所有代码都遵循设
设计模式是五大或六大还是七大原则?
cadenzasolo的专栏
01-23 3000
设计模式是五大或六大还是七大原则?设计模式有五大原则或七大原则之分 按五大原则划分：1、2、3和4（算一种）、5和6（算一种）、7 按六大原则划分：1、2、3、4、5和6（算一种）、7 按七大原则划分：1、2、3、4、5、6、71.单一职责原则(Single Responsibility Principle,SRP)：类的职责要单一，不能将太多的职责放在一个类中。（高内聚、低耦合）2.开闭原则
(一)js前端开发中设计模式前篇之对象
最新发布
峰会路转的博客
07-17 229
改进版与基础版要分开测试，不然会互相影响到。
java 设计模式 七大原则
09-14
Java设计模式的七大原则包括： 1) 单一职责原则：一个类应该只有一个引起变化的原因，即一个类应该只有一个职责。 2) 接口隔离原则：客户端不应该依赖它不需要的接口。应该将接口细分为更小的接口，以便于客户端只需依赖于它们所需的接口。 3) 依赖倒转原则：高级模块不应该依赖于低级模块，二者都应该依赖于抽象。抽象不应该依赖于具体实现，而具体实现应该依赖于抽象。 4) 里氏替换原则：子类对象在任何场景下都可以替换父类对象，而不会引起任何错误或异常。 5) 开闭原则（OCP）：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即当需要添加新的功能时，应该通过扩展已有的代码来实现，而不是修改原有的代码。 6) 迪米特法则：一个对象应该尽可能少地与其他对象之间发生相互作用。 7) 合成复用原则：尽量使用对象组合，而不是继承来达到复用的目的。 以上是Java设计模式的七大原则。通过遵循这些原则，可以使代码更加灵活、可扩展、易维护，并提高代码的质量和可读性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值