面向对象之SOLID

最新推荐文章于 2024-09-17 13:12:15 发布
最新推荐文章于 2024-09-17 13:12:15 发布
阅读量728 收藏
点赞数
分类专栏： 设计模式 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/weixin_42445418/article/details/127997775
版权

本文结合b站和网上的一些资料，主要用于纪录知识。有错则请各位大哥多多指点。

文章目录

前言

不知道你是否曾被混乱的代码结构搞得很难受，无意中了解到SOLID原则，特此纪录一下，希望对各位都有所帮助~
首先复习一下相关的知识
什么是面向对象？

百度百科：面向对象(Object Oriented)是软件开发方法，一种编程范式。面向对象的概念和应用已超越了程序设计和软件开发，扩展到如数据库系统、交互式界面、应用结构、应用平台、分布式系统、网络管理结构、CAD技术、人工智能等领域。面向对象是一种对现实世界理解和抽象的方法，是计算机编程技术发展到一定阶段后的产物。面向对象是相对于面向过程来讲的，面向对象方法，把相关的数据和方法组织为一个整体来看待，从更高的层次来进行系统建模，更贴近事物的自然运行模式。
在我的角度看来，面向对象就是将每个事物都抽象总结为一块积木，每块积木各司其职，共同堆砌成一个在计算机中运行的世界。

什么是SOLID？

SOLID 原则是由 5 个设计原则组成的，分别为：(S)单一职责原则、(O)开闭原则、(L)里式替换原则、(I)接口隔离原则和(D)依赖反转原则。

一、SOLID

SOLID 原则其实是用来指导软件设计的，它一共分为五条设计原则，分别是：

  • 单一职责原则(SRP)，Single Responsibility Principle
  • 开闭原则(OCP)，Open Closed Principle
  • 里氏替换原则(LSP)，Liskov Substitution principle
  • 接口隔离原则(ISP)，Interface Segregation Principle
  • 依赖倒置原则(DIP)，Dependence Inversion Principle

二、详解SOLID

场景:我们需要计算一堆图形的面积和,代码如下

	// 圆
	public class Circle {
	   private final int radius;
	
	   public Circle(int radius) {
	       this.radius = radius;
	   }
	
	   public int getRadius() {
	       return radius;
	   }
	}
	
	// 正方形
	public class Square {
	   private final int length;
	
	   public Square(int length) {
	       this.length = length;
	   }
	
	   public int getLength() {
	       return length;
	   }
	} 
	
	// 面积计算器
	public class AreaCalculator {
	   public int sum(List<Object> shapes) {
	       int sum = 0;
	       for (int i = 0; i < shapes.size(); i++) {
	           Object shape = shapes.get(i);
	           if(shape instanceof Square) {
	               sum += Math.pow(((Square) shape).getLength(), 2);
	           }
	           if(shape instanceof Circle) {
	               sum += Math.PI * Math.pow(((Circle) shape).getRadius(), 2);
	           }
	       }
	       return sum;
	   }
	}
	
	// 主函数
	public class Main {
	   public static void main(String[] args) {
	       AreaCalculator areaCalculator = new AreaCalculator();
	       Circle circle = new Circle(10);
	       Square square = new Square(10);
	       List<Object> circle1 = List.of(circle, square);
	       int sum = areaCalculator.sum(circle1);
	       System.out.println(sum);
	   }
	}

1.单一职责原则（SRP）

需求提出：我们需要以不同的方式打印出面积和，包含但不限于：①Json，②普通格式…

问题引入：先不说计算机的概念，假如你去麦当劳兼职，机器坏了，店长让你去修一下（毕竟你是学计算机的，对吧=，=）。修完之后，让你去刷一下厕所，刷完厕所还得去倒一下垃圾。太多事情了！你晕头转向，上班是竖着进去上班的，下班是横着被人拉出去下班的。发生这种情况的原因就是你一个人干的事情太多了，如果能够分工合作，各司其职的话，就不会造成这样子的情况。那么在计算机里面的世界也是如此~
引入定义

单一职责原则：应该有且仅有一个原因引起类的变更。简单地说：接口职责应该单一，不要承担过多的职责。

反例

代码如下（示例）：

// 直接在AreaCalculator中添加上相关的功能
public class AreaCalculator {
    public int sum(List<Object> shapes) {
        int sum = 0;
        for (int i = 0; i < shapes.size(); i++) {
            Object shape = shapes.get(i);
            if(shape instanceof Square) {
                sum += Math.pow(((Square) shape).getLength(), 2);
            }
            if(shape instanceof Circle) {
                sum += Math.PI * Math.pow(((Circle) shape).getRadius(), 2);
            }
        }
        return sum;
    }
    
	public String Json(List<Object> shapes) {
		return "{sum: %s}".formatted(sum(shapes));
	}
	
	public String csv(List<Object> shapes) { 
		return "sum, %s".formatted(sum(shapes));
	}
}

实话实话，这种写法其实是没啥问题的。但是当功能越来越多，代码就会越来越繁杂，直接导致的后果就是当要再看一遍代码的时候，我相信真的会看吐=，=。而且那么多的功能，灵活的胖子这种情况是不可能发生的。

改进

单一职责原则告诉我们，最好的做法是将这部分功能剥离出来，新建一个类去完成该项功能。但是会不会出现类过多的情况，这得看程序怎么设计了，这种事情都是仁者见仁智者见智的，毕竟没有什么东西可以十全十美╮(╯▽╰)╭。代码如下

	public class shapePrinter {
		public String Json(int sum) {
			return String.format("{shapeSum: %s}", sum);
		}
	
		public String csv(int sum) { 
			return String.format("shapeSum, %s", sum);
		}
	}

2. 开闭原则（OCP）

需求引入：除了圆形、正方形以外，还得加入正方体，毕竟我是老板我任性对吧~

问题引入：说实话，这种问题根本难不倒我们对吧。作为CV工程师，这种小问题不是so easy吗。我要开始写（反例）了

反例

代码如下：

	public class Circle {
	    private final int radius;
	
	    public Circle(int radius) {
	        this.radius = radius;
	    }
	
	    public int getRadius() {
	        return radius;
	    }
	}

	public class AreaCalculator {
	    public int sum(List<Object> shapes) {
	        int sum = 0;
	        for (int i = 0; i < shapes.size(); i++) {
	            Object shape = shapes.get(i);
	            if(shape instanceof Square) {
	                sum += Math.pow(((Square) shape).getLength(), 2);
	            }
	            if(shape instanceof Circle) {
	                sum += Math.PI * Math.pow(((Circle) shape).getRadius(), 2);
	            }
	            if(shape instanceof Cube) {
	                sum += 6 * Math.pow(((Square) shape).getLength(), 2);
	            }
	        }
	        return sum;
    	}
	}

说实话，这种写法也是完全可以的~ 但是问题在于，任性的老板不定时提个需求，毕竟图形有辣么多对吧。然后我们就得一直写if…最后又收获了一堆复杂的代码，哎
那么有什么好的设计方法可以避免这种情况的发生呢？
引入定义

一个软件实体，如类、模块和函数应该对扩展开放，对修改关闭。简单地说：就是当别人要修改软件功能的时候，使得他不能修改我们原有代码，只能新增代码实现软件功能修改的目的。

改进

针对这个例子，应该这样子修改

	public interface Shape {
	    double area();
	}
	
	public class Circle implements Shape{
	    private final int radius;
	
	    public Circle(int radius) {
	        this.radius = radius;
	    }
	
	    public int getRadius() {
	        return radius;
	    }
	
	    @Override
	    public double area() {
	        return Math.PI * Math.pow(getRadius(), 2);
	    }
	}
	
	public class Square implements Shape{
	    private final int length;
	
	    public Square(int length) {
	        this.length = length;
	    }
	
	    public int getLength() {
	        return length;
	    }
	
	    @Override
	    public double area() {
	        return Math.pow(getLength(), 2);
	    }
	}
	
	public class Cube implements Shape{
	    private final int length;
	
	    public Cube(int length) {
	        this.length = length;
	    }
	
	    public int getLength() {
	        return length;
	    }
	
	    @Override
	    public double area() {
	        return 6 * Math.pow(this.length, 2);
	    }
	}

	
	public class AreaCalculator {
	    public int sum(List<Shape> shapes) {
	        int sum = 0;
	        for (int i = 0; i < shapes.size(); i++) {
	            sum += shapes.get(i).area();
	        }
	        return sum;
	    }
	}

    public static void main(String[] args) {
        AreaCalculator areaCalculator = new AreaCalculator();
        Circle circle = new Circle(10);
        Square square = new Square(10);
        List<Shape> circle1 = List.of(circle, square);
        int sum = areaCalculator.sum(circle1);
        System.out.println(sum);
    }

代码分析：让我们看一下代码怎么变化，首先定义了一个接口Shape这个接口定义了一个方法double area(),然后给Circle，Square，等图形实现，同时AreaCalculator也修改为sum += shapes.get(i).area()。现在新增一个图形就不用改AreaCalculator咯，只需要实现Shape接口就好啦。很方便有木有！
所以开闭原则就是对修改关闭，对新增关闭。用人话就是说，新增功能不用修改已有的代码，这样子真的是太棒啦~

3.单一职责原则（SRP）

需求引入：奇怪的老板又来了，他买的股票带有Shape字样的跌成狗，就觉得Shape这个类不顺眼，要全改。没办法，只能安装老板的意思改，有人想到可以把Shape的子类给他放进去，对吧
这样子说好像只是感觉老板在发颠，实际不会出现这种情况。换优快云一篇文章的情景，有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。

在这里插入图片描述

反例

大佬们说的头头是道，那我这个小菜鸡写一下代码：

public class NoShape implements Shape{
    @Override
    public double area() {
        throw new RuntimeException("不是一个图形");
    }
}

很明显，当我们把这段代码放进main程序，必定会报错。因为我们抛出了异常=，=。这就违反了里氏替换原则，子类影响了父类的地方。

优快云这篇文章说的特别好，六大设计原则SOLID
在学习java类的继承时，我们知道继承有一些优点：

  • 子类拥有父类的所有属性和方法，从而可以减少创建类的工作量。
  • 提高了代码的重用性。
  • 提高了代码的扩展性， 子类不但拥有了父类的所有功能，还可以添加自己的功能。

但有优点也同样存在缺点

  • 继承是侵入性的。只要继承，就必须拥有父类的方法和属性。
  • 降低了代码的灵活性。因为继承时，父类会对子类有一种约束。
  • 增强了耦合性。 当需要对父类的代码进行修改时，必须考虑到对子类产生的影响。

如何扬长避短呢？方法是引入里氏替换原则。

里氏替换原则对继承进行了规则上的约束，这种约束主要体现在四个方面：

  • 子类必须实现父类的抽象方法，但不得重写（覆盖）父类的非抽象(已实现)方法。
  • 子类中可以增加自己特有的方法。
  • 当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。（即只能重载不能重写）
  • 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

里氏替换原则 LSP 重点强调：对使用者来说，能够使用父类的地方，一定可以使用其子类，并且预期结果是一致的。换句话说， 所有基类在的地方， 都可以换成子类， 程序还可以正常的运行。这个原则是与面向对象语言的继承特性密切相关的。
当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。

4.接口隔离原则（ISP）

需求引入：立方体是个三维图形，辣么他有体积吧，你们帮我把它体积也求出来！老板如是说。

问题分析：这些图形都是实现了Shape接口，那么在这个接口加上不就好了吗？聪明的我说干就干

反例

	public interface Shape {
	    double area();
	    double volume();
	}
	
	public class Cube implements Shape{
	    private final int length;
	
	    public Cube(int length) {
	        this.length = length;
	    }
	
	    public int getLength() {
	        return length;
	    }
	
	    @Override
	    public double area() {
	        return 6 * Math.pow(this.length, 2);
	    }
		
		@Override
		public double volume() {
			return Math.pow(this.length, 3);
		}
	}

坏了，平面的图形肿么办！？直接return 0好了，╮(╯▽╰)╭。然后你会收获一堆繁杂而且没用的代码，给自己增加工作量啊！(ˉ▽ˉ；)…

那么有什么好的设计方法可以避免这种情况的发生呢？
引入定义

类间的依赖关系中，子类不应被强迫依赖它不需要的接口，而应该建立在最小的接口上。简单地说：接口的内容一定要尽可能地小，能有多小就多小。
注： 该原则中的接口， 是一个泛泛而言的接口， 不仅仅指java中的接口，还包括其中的抽象类。
其实通俗来理解就是， 不要在一个接口里面放很多的方法，这样会显得这个类很臃肿不堪。接口应该尽量的细化，一个接口对应一个功能模块，同时接口里面的方法应该尽量的少，使接口尽可能的轻便灵活。

改进

因此，正确的解决方法应该是这样子：

	public interface ThreeDimensionalShape {
	    public double volume();
	}
	
	public class Cube implements Shape, ThreeDimensionalShape{
	    private final int length;
	
	    public Cube(int length) {
	        this.length = length;
	    }
	
	    public int getLength() {
	        return length;
	    }
	
	    @Override
	    public double area() {
	        return 6 * Math.pow(this.length, 2);
	    }
	
	    @Override
	    public double volume() {
	        return Math.pow(this.length, 3);
	    }
	}

如上面的代码，Shape只提供二维可能出现的情况，新开一个接口ThreeDimensionalShape用于提供三维可能出现的情况。三维图形才去实现这个接口╮(╯▽╰)╭。

依赖反转原则（DIP）

需求引入，现在AreaCalculator不是求和了，是求积了，那么我们改怎么办呢？

根据开闭原则，我们应该先优化一下代码

public interface IAreaCalculator {
    public int sum(List<Shape> shapes);
}


public class AreaCalculator implements IAreaCalculator{
    @Override
    public int sum(List<Shape> shapes) {
        int sum = 0;
        for (int i = 0; i < shapes.size(); i++) {
            sum += shapes.get(i).area();
        }
        return sum;
    }
}

public class ShapePrinter {
    private final IAreaCalculator areaCalculator;

    public ShapePrinter(IAreaCalculator areaCalculator) {
        this.areaCalculator = areaCalculator;
    }

    public String Json(List<Shape> shapes) {
        return String.format("{shapeSum: %s}", areaCalculator.sum(shapes));
    }

    public String csv(List<Shape> shapes) {
        return String.format("shapeSum, %s", areaCalculator.sum(shapes));
    }
}

public class Main {
    public static void main(String[] args) {
        AreaCalculator areaCalculator = new AreaCalculator();
        Circle circle = new Circle(10);
        Square square = new Square(10);
        ShapePrinter shapePrinter = new ShapePrinter(areaCalculator);
        List<Shape> circle1 = List.of(circle, square);
        System.out.println(shapePrinter.Json(circle1));
        System.out.println(shapePrinter.csv(circle1));
    }
}

说实话，聪明的我随便就能做出来~

反例

public class AreaCalculatorV2 implements IAreaCalculator{
    @Override
    public int sum(List<Shape> shapes) {
        int sum = 0;
        for (int i = 0; i < shapes.size(); i++) {
            sum *= shapes.get(i).area();
        }
        return sum;
    }
}

public class Main {
    public static void main(String[] args) {
        AreaCalculatorV2 areaCalculator = new AreaCalculatorV2();
        Circle circle = new Circle(10);
        Square square = new Square(10);
        ShapePrinter shapePrinter = new ShapePrinter(areaCalculator);
        List<Shape> circle1 = List.of(circle, square);
        System.out.println(shapePrinter.Json(circle1));
        System.out.println(shapePrinter.csv(circle1));
    }
}

简直轻而易举~太简单啦，我们这里啥都没改，只是新增了一个类去实现一个接口。然鹅，你会发现，如果又要改回AreaCalculator, 主函数又得改，(ˉ▽ˉ；)…
那有什么方法可以避免这种情况呢？
引入定义

依赖反转原则:高层模块不依赖低层模块，它们共同依赖同一个抽象。抽象不要依赖具体实现细节，具体实现细节依赖抽象。这里的高层模块为调用者，底层模块为被调用者；

改进

其实只需要小改一下就好了，改成介样子—>IAreaCalculator areaCalculator = new AreaCalculator();

public class Main {
    public static void main(String[] args) {
        IAreaCalculator areaCalculator = new AreaCalculator();
        Circle circle = new Circle(10);
        Square square = new Square(10);
        ShapePrinter shapePrinter = new ShapePrinter(areaCalculator);
        List<Shape> circle1 = List.of(circle, square);
//        int sum = areaCalculator.sum(circle1);
        System.out.println(shapePrinter.Json(circle1));
        System.out.println(shapePrinter.csv(circle1));
    }
}

这样子改完美的遵守了开闭原则。太牛啦！

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。 以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。 在java中， 抽象指的契约，是接口或者抽象类， 细节就是具体的实现类， 使用接口或者抽象类的目的是制定好的规范和而不去设计任何具体的操作， 把展示细节的任务交给他们的实现类去完成。

总结

这篇文章总结的很好~

  • 单一职责是所有设计原则的基础，开闭原则是设计的终极目标。
  • 里氏替换原则强调的是子类替换父类后程序运行时的正确性，它用来帮助实现开闭原则。
  • 而接口隔离原则用来帮助实现里氏替换原则，同时它也体现了单一职责。
  • 依赖倒置原则是过程式编程与面向对象编程的分水岭，同时它也被用来指导接口隔离原则。

在这里插入图片描述

简单地说：依赖倒置原则告诉我们要面向接口编程。当我们面向接口编程之后，接口隔离原则和单一职责原则又告诉我们要注意职责的划分，不要什么东西都塞在一起。
当我们职责捋得差不多的时候，里氏替换原则告诉我们在使用继承的时候，要注意遵守父类的约定。而上面说的这四个原则，它们的最终目标都是为了实现开闭原则

相比于23种设计模式，SOLID原则更加通用，主要的思想还是解耦，真的可以认真学一下~

面向对象设计的 SOLID 原则
albon arith
05-26 937
文章目录依赖倒置原则接口隔离单一职责开闭原则里氏替换原则迪米特法则资料 依赖倒置原则 高级模块不应当依赖于低级模块。它们都应当依赖于抽象。 抽象不应当依赖于实现，实现应当依赖于抽象。 依赖倒置原则存在的真正意义是指，我们需要将一些对象解耦，它们的耦合关系需要达到当一个对象依赖的对象作出改变时，对象本身不需要更改任何代码。 这样的架构可以实现一种松耦合的状态的系统，因为系统中所有的组件，彼此之间...
面向对象设计中的五大SOLID原则
最新发布
luotuo28的博客
02-19 903
面向对象设计中的五大SOLID原则是指导软件设计和开发的重要原则，旨在提高代码的可维护性、可扩展性和可复用性。
面向对象设计的SOLID原则
nowgoant的专栏
05-06 472
<br /><br />S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。<br />SRP The Single Responsibility Principle <br />  单一责任原则 <br /> OCP The Open Closed Principle <br />  开放封闭原则 <br /> LSP The Liskov Substitution Principle 里氏替换原则 <br /> D
SOLID (面向对象设计)
Evan的博客
03-11 1149
-来自维基百科，自由的百科全书在 程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在21世纪早期引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。SOLID所包含的原则是通过引发编程者进行软件源代码的代码重构进行软件的代码异味清扫，从
OO五大原则（3.LSP——里氏替换原则）
弦上爱的专栏
03-20 1808
 OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。 “抽象”是语言提供的功能。“多态”由继承语义实现。 如此，问题产生了：“我们如何去度量继承关系的质量？” Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any
面向对象设计的SOLID原则 .docx
04-15
SOLID 原则是面向对象设计和编程（OOD&OOP）中几个重要编码原则的首字母缩写，分别是单一责任原则、开放封闭原则、里氏替换原则、依赖倒置原则和接口分离原则。这些原则是非常基础而且重要的面向对象设计原则，理解...
ood-solid:面向对象设计的SOLID原理
03-06
在面向对象设计中，SOLID原则是一个核心概念，它由五条基本的设计原则组成，能够帮助我们创建出可维护、可扩展和易于理解的代码。这五条原则分别是单一职责原则（Single Responsibility Principle, SRP）、开闭原则...
injector:递归依赖注入器，用于引导和连接面向对象的SOLID SOLID应用程序
03-16
一个递归依赖注入器，用于引导和连接SOLID，面向对象PHP应用程序。 怎么运行的 除其他外，注入器根据类构造函数签名中指定的参数类型提示来递归实例化类依赖关系。 这需要使用反射。 您可能听说过“反射很慢”。 让...
设计模式原则SOLID
Striver Blog
11-16 4241
设计模式五大原则： 单一职责原则SRP告诉我们实现类要职责单一； 里氏替换原则LSP告诉我们不要破坏继承体系； 依赖倒置原则DIP告诉我们要面向接口编程； 接口隔离原则ISP告诉我们在设计接口的时候要精简单一； 开闭原则OCP是总纲，他告诉我们要对扩展开放，对修改关闭。 迪米特法则告诉我们要降低耦合。
阿里巴巴编码规范解读（六、七）-工程结构及设计规约
gonghaiyu的博客
08-01 1361
工程结构 应用分层 1.【推荐】 图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层可以依赖于 Web层，也可以直接依赖于 Service层，依此类推。 开放接口层：可直接封装 Service 方法暴露成RPC 接口；通过Web 封装成http 接口；网关控制层等。 终端显示层：各个端的模板渲染并执行显示的层。当前主要是velocity 渲染，JS 渲染，JSP 渲染，移 动端展示等。 Web 层：主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。 Service 层：相
浅谈SOLID面向对象设计
ghostyusheng 's blog
07-17 358
S (Single responsibility principle)  单一职责原则 O (Open-Closed principle） 开放封闭原则 L (Liskov Substitution principle) 里式替换原则 I (Interface-segregation principles) 接口隔离原则 D (Dependency inversion principle)...
面向对象设计原则-SOLID原则
老薛的专栏
09-17 251
SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转），指代了面向对象编程和的五个基本原则。当这些原则被一起应用时，它们使得一个程序员开发一个容易进行软件维护和扩展的系统变得更加可能。
面向对象的五大基本设计原则：SOLID
Gyp郭小帅的博客
04-08 580
什么是设计原则 ⾯向对象过程中，前辈⼤咖们推荐的⼀些指导性原则，遵循这些原则可以让你的设计更有竞争力。 一、单⼀职责原则（SRP：Single Responsibility Principle） 背景： 单⼀职责原则，SRP⼜称单⼀功能原则，⾯向对象五个基本原则（SOLID）之⼀。它规定⼀个类应 该只有⼀个发⽣变化的原因。该原则由罗伯特·C·⻢丁（Robert C. Martin）于《敏捷软件开发：原 则、模式和实践》⼀书中给出的。 ------------------------.
面向对象设计的五大原则（SOLID 原则）
alittlefish1的博客
09-12 1354
面向对象设计的五大原则（SOLID 原则）是指导我们设计可维护、灵活且易扩展的面向对象系统的核心准则。这些原则帮助开发者避免常见的设计陷阱，使代码更具可读性和可维护性。
面向对象法则SOLID
12-28
### 面向对象 SOLID 原则解释 #### 单一职责原则 (SRP) 单一职责原则指出每一个类应该只有一个引起它变化的原因。这意味着一个类应当只负责一项功能领域中的相应职责[^1]。 ```java // 违反 SRP 的例子 class User { public void register(); public void sendEmailNotification(); // 不同的责任混在一起 } // 符合 SRP 的重构版本 class UserService { private UserRepository userRepository; public void register() { /* 注册逻辑 */ } } class EmailService { public void sendEmailNotification(User user) {/* 发送邮件通知 */} } ``` #### 开闭原则 (OCP) 开闭原则强调软件实体（类、模块、函数等等）应该是可以扩展的，但是不可修改。这意在鼓励通过增加新代码来实现新的行为而不是改变现有的代码[^4]。 ```csharp public interface IShape { double Area(); } public class Circle : IShape { public double Radius { get; set; } public double Area() => Math.PI * Radius * Radius; } public class Rectangle : IShape { public double Width { get; set; } public double Height { get; set; } public double Area() => Width * Height; } // 新增形状不需要改动已有的类 public class Square : IShape { public double SideLength { get; set; } public double Area() => SideLength * SideLength; } ``` #### 里氏替换原则 (LSP) 该原则规定子类型必须能够替换它们的基类型而不影响程序的正确性。换句话说，任何父类型的实例出现的地方都可以被其子类型所替代[^3]。 ```cpp #include <iostream> using namespace std; class Bird { public: virtual void fly() const = 0; }; class Sparrow : public Bird { public: void fly() const override { cout << "Sparrow flying\n"; } // 正确的行为 }; class Ostrich : public Bird { public: void fly() const override { throw runtime_error("Ostrich can't fly"); } // 错误的行为违反 LSP }; ``` #### 接口隔离原则 (ISP) 接口隔离原则建议客户端不应该被迫依赖于那些不使用的接口；多个特定客户专用的接口要好过一个通用的大接口[^2]。 ```typescript interface IPrinter { print(): void; } interface IScanner { scan(): void; } // 使用者只需要关心自己需要的功能即可 class PhotoCopier implements IPrinter, IScanner { print() {} scan() {} } class NetworkPrinter implements IPrinter { print() {} } ``` #### 依赖倒置原则 (DIP) 高层模块不应依赖低层模块，两者都应该依赖抽象；抽象不应依赖细节，细节应依赖抽象。此原则有助于减少耦合度并提高灵活性和可测试性。 ```python from abc import ABC, abstractmethod # 抽象化 class Switchable(ABC): @abstractmethod def turn_on(self): pass @abstractmethod def turn_off(self): pass # 细节实现 class LightBulb(Switchable): def turn_on(self): print('Light bulb is on') def turn_off(self): print('Light bulb is off') def switch(switchable_item: Switchable): switchable_item.turn_on() # do something... switchable_item.turn_off() light_bulb = LightBulb() switch(light_bulb) ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值