设计模式之七大原则

最新推荐文章于 2024-10-17 19:11:48 发布
最新推荐文章于 2024-10-17 19:11:48 发布
阅读量457 收藏
点赞数
分类专栏： 设计模式 文章标签： java 设计模式
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_48465257/article/details/118367453
版权

文章目录

设计模式的目的

  • 重用性：相同功能的代码，不用多次编写。
  • 可读性：编程规范性，便于其他程序员的阅读和理解。
  • 可扩展性：当需要增加新的功能时，非常的方便。
  • 可靠性：当增加新的功能后，对原来的功能没有影响。
  • 使程序呈现高内聚，低耦合的特性。

单一职责原则

基本介绍

  • 对类来说，级一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。

案例

  • 不遵循单一职责原则
public class SingleResponsibility01 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("汽车");
        vehicle.run("飞机");
        vehicle.run("轮船");
    }
}

class Vehicle{
    public void run(String vehicle){
        System.out.println(vehicle + "在公路上跑......");
    }  
}

在这里插入图片描述

  • 遵循单一职责原则
public class SingleResponsibility02 {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.runRoad("汽车");
        vehicle.runAir("飞机");
        vehicle.runWater("轮船");
    }
}
//虽然并没有在类上满足单一职责原则，但在方法上满足单一职责原则
class Vehicle{
    public void runRoad(String vehicle){
        System.out.println(vehicle + "在公路上跑......");
    }
    
    public void runAir(String vehicle){
        System.out.println(vehicle + "在天空上飞......");
    }
    
    public void runWater(String vehicle){
        System.out.println(vehicle + "在水中游......");
    }
}

在这里插入图片描述

注意事项和细节

  • 降低类的复杂性，一个类只负责一项职责。
  • 提高类的可读性，可维护性。
  • 降低变更引起的风险。
  • 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则。

接口隔离原则

基本介绍

  • 客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。

案例

  • 不遵循解扣隔离原则
    在这里插入图片描述
interface Interface1{
    void operation1();
    void operation2();
    void operation3();
    void operation4();
    void operation5();
}

class B implements Interface1{
    @Override
    public void operation1() {
        System.out.println("B 实现了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("B 实现了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("B 实现了 operation3");
    }

    @Override
    public void operation4() {
        System.out.println("B 实现了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("B 实现了 operation5");
    }
}

class D implements Interface1{
    @Override
    public void operation1() {
        System.out.println("D 实现了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("D 实现了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("D 实现了 operation3");
    }

    @Override
    public void operation4() {
        System.out.println("D 实现了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("D 实现了 operation5");
    }    
}

class A{
    public void depend1(Interface1 i){
        i.operation1();
    }
    
    public void depend2(Interface1 i){
        i.operation2();
    }
    
    public void depend3(Interface1 i){
        i.operation3();
    }   
}

class C{
    public void depend1(Interface1 i){
        i.operation1();
    }
    
    public void depend4(Interface1 i){
        i.operation4();
    }
    
    public void depend5(Interface1 i){
        i.operation5();
    }    
}
  • 遵循接口隔离原则
    在这里插入图片描述
interface Interface1{
    void operation1();
}

interface Interface2{

    void operation2();  
    void operation3();
}
interface Interface3{

    void operation4(); 
    void operation5();

}

class B implements Interface1, Interface2{
    @Override
    public void operation1() {
        System.out.println("B 实现了 operation1");
    }

    @Override
    public void operation2() {
        System.out.println("B 实现了 operation2");
    }

    @Override
    public void operation3() {
        System.out.println("B 实现了 operation3");
    }
}

class D implements Interface1, Interface3{
    @Override
    public void operation1() {
        System.out.println("D 实现了 operation1");
    }

    @Override
    public void operation4() {
        System.out.println("D 实现了 operation4");
    }

    @Override
    public void operation5() {
        System.out.println("D 实现了 operation5");
    }  
}

class A{
    public void depend1(Interface1 i){
        i.operation1();
    }
    
    public void depend2(Interface2 i){
        i.operation2();
    }
    
    public void depend3(Interface2 i){
        i.operation3();
    }    
}

class C{
    public void depend1(Interface1 i){
        i.operation1();
    }
    
    public void depend4(Interface3 i){
        i.operation4();
    }
    
    public void depend5(Interface3 i){
        i.operation5();
    }   
}

依赖倒转原则

基本介绍

  • 高层模块不应该依赖底层模块，二者都应该依赖其抽象。
  • 抽象不应该依赖细节，细节应该依赖抽象。
  • 依赖倒转的中心思想是面向接口编程。
  • 依赖倒转原则是基于这样的设计理念：相对于细节的多边形，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类。
  • 使用解扣或者抽象类的目的是制定好规范，而不涉及任何具体操作，把展现细节的任务交给他们的实现类去做。
  • 依赖关系传递的三种方式：接口传递、构造方法传递、setter方式传递。

案例

  • 不遵循依赖倒转原则
public class DependencyInversion01 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
    }  
}

class Email{
    public String getInfo(){
        return "邮件：hello, world!";
    }    
}

//如果获取对象为微信，短信等，则增加新类，Person也要增加相应的方法
class Person{

    public void receive(Email email){
        System.out.println(email.getInfo());
    }    
}
  • 遵循依赖倒转原则
public class DependencyInversion02 {
    public static void main(String[] args) {
        Person person = new Person();
        person.receive(new Email());
        person.receive(new WeiXin());
    }    
}

interface IReceive{
    String getInfo();    
}

class Email implements IReceive{
    @Override
    public String getInfo() {
        return "邮件：hello world!";
    }    
}

class WeiXin implements IReceive{
    @Override
    public String getInfo() {
        return "微信：hello world!";
    }    
}

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

注意事项和细节

  • 底层模块尽量都要有抽象类或者接口，或者两者都有，程序稳定性更好。
  • 变量的声明类型尽量是抽象类或者接口，这样我们的变量引用和实际对象间，就存在一个缓冲层，利于程序扩展和优化。
  • 继承时遵循里氏替换原则。

里氏替换原则

基本介绍

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

案例

  • 不遵循里氏替换原则
public class Liskov {
    public static void main(String[] args) {    
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));
        System.out.println("==============");
        
        B b = new B();
        System.out.println("11-3=" + b.func1(11, 3));
        System.out.println("1-8=" + b.func1(1, 8));
        System.out.println("11+3+9=" + b.func2(11, 3));        
    }
}

class A{
    public int func1(int num1, int num2){
        return num1 - num2;
    }    
}

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

    public int func2(int a, int b){
        return func1(a, b) + 9;
    }   
}

在这里插入图片描述

  • 满足里氏替换原则
public class Liskov {
    public static void main(String[] args) { 
        A a = new A();
        System.out.println("11-3=" + a.func1(11, 3));
        System.out.println("1-8=" + a.func1(1, 8));
        System.out.println("==============");
        
        B b = new B();
        System.out.println("11+3=" + b.func1(11, 3));
        System.out.println("1+8=" + b.func1(1, 8));
        System.out.println("11+3+9=" + b.func2(11, 3));
        System.out.println("11-3=" + b.func3(11, 3));     
    }
}

//解决方法：原来的父类和子类都继承一个更加通俗的基类，原有继承关系去掉，采用依赖，聚合，组合替代
class Base{
}

class A extends Base{
    public int func1(int num1, int num2){
        return num1 - num2;
    }    
}

class B extends Base{
    //B需要使用A中的方法，用组合关系
    private A a = new A();

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

    public int func2(int a, int b){
        return func1(a, b) + 9;
    }

    public int func3(int a, int b){
        return this.a.func1(a, b);
    }   
}

在这里插入图片描述

开闭原则

基本介绍

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

案例

  • 不遵循开闭原则
public class Ocp {
    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShape(new Circle());
        graphicEditor.drawShape(new Rectangle());
    }
}

//增加新图形时需要修改很多地方
class GraphicEditor{
    public void drawShape(Shape shape){
        if (shape.type == 1){
            drawRectangle();
        } else if (shape.type == 2){
            drawCircle();
        }
    }

    public void drawRectangle(){
        System.out.println("矩形");
    }

    public void drawCircle(){
        System.out.println("圆形");
    }
}

class Shape{
    int type;    
}

class Rectangle extends Shape{
    Rectangle(){
        super.type = 1;
    }    
}

class Circle extends Shape{
    Circle(){
        super.type = 2;
    }    
}
  • 遵循开闭原则
public class Ocp {
    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShape(new Circle());
        graphicEditor.drawShape(new Rectangle());
    }
}

//增加新图形时需要修改很多地方
class GraphicEditor{
    public void drawShape(Shape shape){
        shape.draw();
    }
}

interface Shape{
    void draw();    
}

class Rectangle implements Shape{
    @Override
    public void draw() {
        System.out.println("矩形");
    }  
}

class Circle implements Shape{
    @Override
    public void draw() {
        System.out.println("圆形");
    }   
}

迪米特法则

基本介绍

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

案例

  • 不遵循迪米特法则
public class Demeter {
    public static void main(String[] args) {
        SchoolManage schoolManage = new SchoolManage();
        schoolManage.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(){
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId("学院员工id="+i);
            list.add(collegeEmployee);
        }
        return list;
    }    
}

//直接朋友：Employee  CollegeManager
//CollegeEmployee不是直接朋友
class SchoolManage{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee employee = new Employee();
            employee.setId("学校总部员工id="+i);
            list.add(employee);
        }
        return list;
    }

    void printAllEmployee(CollegeManager manager){
        List<CollegeEmployee> employeeList = manager.getAllEmployee();
        for (CollegeEmployee collegeEmployee : employeeList) {
            System.out.println(collegeEmployee.getId());
        }
        System.out.println("======================");
        List<Employee> employeeList1 = this.getAllEmployee();
        for (Employee employee : employeeList1) {
            System.out.println(employee.getId());
        }
    }
}
  • 遵循迪米特法则
public class Demeter {
    public static void main(String[] args) {
        SchoolManage schoolManage = new SchoolManage();
        schoolManage.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(){
        List<CollegeEmployee> list = new ArrayList<>();
        for (int i = 0; i < 10; i++) {
            CollegeEmployee collegeEmployee = new CollegeEmployee();
            collegeEmployee.setId("学院员工id="+i);
            list.add(collegeEmployee);
        }
        return list;
    }

    public void printEmployee(){
        List<CollegeEmployee> employeeList = this.getAllEmployee();
        for (CollegeEmployee collegeEmployee : employeeList) {
            System.out.println(collegeEmployee.getId());
        }
    }
}

//直接朋友：Employee  CollegeManager
//CollegeEmployee不是直接朋友
class SchoolManage{
    public List<Employee> getAllEmployee(){
        List<Employee> list = new ArrayList<>();
        for (int i = 0; i < 5; i++) {
            Employee employee = new Employee();
            employee.setId("学校总部员工id="+i);
            list.add(employee);
        }
        return list;
    }

    void printAllEmployee(CollegeManager manager){
        manager.printEmployee();
        System.out.println("======================");
        List<Employee> employeeList1 = this.getAllEmployee();
        for (Employee employee : employeeList1) {
            System.out.println(employee.getId());
        }
    }
}

注意事项和细节

  • 迪米特法则和核心是降低类之间的耦合。
  • 注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间耦合关系，并不是要求完全没有依赖关系。

合成复用原则

基本介绍

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

设计原则核心思想

  • 找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。
  • 针对接口编程，而不是针对实现编程。
  • 为了交互对象之间的松耦合而努力设计。
独守丶轩
关注
专栏目录
设计模式——七大设计原则
weixin_43412762的博客
12-05 3132
设计模式的七大原则：开闭原则、里氏代换原则、依赖倒转原则、接口隔离原则、合成复用原则、迪米特法则
详细介绍设计模式七大原则
m0_54187478的博客
02-19 2666
单一职责原则：一个类应该只有一个引起它变化的原因。开闭原则：软件实体应对扩展开放，对修改封闭。里氏替换原则：子类型必须能够替换掉它们的基类型。依赖倒置原则：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。接口隔离原则：使用多个专门的接口比使用单一的总接口更好。合成/聚合复用原则：尽量使用对象的组合/聚合，而不是继承关系达到复用的目的。迪米特法则（最少知道原则）：一个对象应对其他对象有尽可能少的了解。
Java设计模式之七大设计原则
热门推荐
qq_49529322的博客
04-28 1万+
Java设计模式之七大设计原则 本文对Java设计模式中的七大设计原则进行汇总介绍，提炼最核心的概念。 设计模式总结笔记 一、设计模式七大原则 设计模式的目的： 代码可重用性：相同功能的代码，不用多次编写。 可读性：编程规范性，便于其他程序员的阅读和理解。 可扩展性：当需要增加新的功能的时候，非常方便，称为可扩展性。 可靠性：当我们新增功能后，对原来的功能没有影响。 使程序呈现高内聚、低耦合特性。 1.1、单一职责原则 不遵守单一职责原则： 对类来说的，就是一个类应该只负责一项职责。 比如：Us
设计模式七大原则
java123456111的博客
05-18 4642
1、设计模式的目的 ​ 编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性 等多方面的挑战，设计模式是为了让程序(软件)，具有更好 ​ 1) 代码重用性 (即：相同功能的代码，不用多次编写) ​ 2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解) ​ 3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护) ​ 4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响) ​ 5) 使程序呈现高内聚，低耦合的特性 2、设计模式七大原则 ​ 设计模
设计模式七大原则——开闭原则
★★光亭★★
02-06 1万+
设计模式七大原则——开闭原则
设计模式七大原则——迪米特原则
★★光亭★★
02-06 8961
设计模式七大原则——迪米特原则
【设计模式】23种设计模式之七大原则
javaScript1997的博客
03-22 2164
设计模式原则：是程序员在编程时应当遵循的原则，是各种设计模式的基础，即设计模式为什么这样设计的依据对类来说，即一个类应该只负责一项职责，如类A负责两个不同职责：职责1、职责2。当职责1需求变更而改变A时，可能造成职责B执行错误，所以需要将类A的粒度分解为A1、A2客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上①高层模块不应该依赖低层模块，二者都应该依赖其抽象；②抽象不应该依赖细节，细节应该依赖抽象；③依赖倒转的中心思想是面向接口编程。
设计模式之七大设计原则详解
aaa31203的博客
08-22 1万+
七大设计原则： 七大设计原则：开闭原则、依赖倒置原则、单一职责原则、接口隔离原则、迪米特原则、里氏替换原则、合成复用原则 Java 有三大特性：封装、继承、多态。 而这七大设计原则，更像是对三大特性的一种体现。 七大原则并不是分别独立的原则，他们之间是相互有联系的，甚至可以看做是一体的。 有时候你为了符合某种原则会无意之间破坏另一个原则 有时候你为了符合某种原则还会发现这也符合另外几种原则 开闭原则 对（类、方法）扩展开放，对修改关闭。 开闭原则是七大设计原则中最基础的一个。 我觉得开闭很好理解，但是对 扩
设计模式——设计模式简介和七大原则
vincewm的博客
04-28 1553
设计模式的目的和核心原则、单一职责原则、接口隔离原则、依赖倒转原则、里氏替换原则、开闭原则、迪米特法则、合成复用原则
最通俗易懂--设计模式之七大原则
Z_DingHao的博客
03-09 1706
我写的这一系列设计模式，可能会围绕Java+Android来举例，但是不影响阅读。设计模式是什么？ 设计模式是广大程序员长年累月的经验总结。这门课也不是太容易，我尽量理解，也尽量说的简洁并通俗易懂，共同学习。 设计模式有什么用？ 优化你的代码，让代码可读性强，适用性高，软件体系更加灵活。 回看一下自己的代码有没有一种牵一发而动全身的害怕，稍微更改一点就要崩溃，设计模式就是来解决这些问题
第一章设计模式与七大原则.doc
02-28
设计模式是软件工程中的一种重要思想，它是经验丰富的软件开发者在实践中提炼出来的一套解决方案模板。...在实际开发中，选择合适的设计模式和遵循设计原则，可以帮助我们构建出更加优雅、可扩展的系统。
Java设计模式七大原则-单一职责原则.md
08-13
设计模式
12-附录 1 设计模式的七大原则(1).html
04-01
在书中，作者们将这二十三种设计模式分成了三类，分别是创建型模式、结构型模式和行为型模式。 创建型模式包含了： 工厂方法模式（ Factory Method ） 抽象工厂模式（ Abstract Factory ） 单例模式（ Singleton ...
C# 设计模式的七大原则详解
仰望星空的博客
04-12 807
在 C# 编程中，设计模式的七大原则是保证代码质量和可维护性的基石。这些原则不仅仅是理论上的指导，更是在实际项目开发中的重要实践。本文将详细解释每个原则，并附上相应的 C# 示例代码，帮助读者更好地理解和应用这些原则。
【C++刷题】力扣-#121-买卖股票的最佳时机
会写代码的饭桶
10-16 573
给定一个数组 prices，其中 prices[i] 表示第 i 天的股票价格。假设你可以在第 i 天买入并在第 j 天卖出股票（i ≤ j），设计一个算法来计算你所能获取的最大利润。注意你只能持有一股股票，并且你不能同时参与多笔交易（即在再次买入前必须卖出股票）。
java 异常包装
最新发布
fdvvg的博客
10-17 355
通过异常包装，可以在Java中有效地处理和传递异常。这样做不仅能保持原始异常的信息，还能为上层调用者提供更多的上下文信息。
基于SSM班级事务管理系统的设计
2401_87849773的博客
10-15 441
管理员账户功能包括：系统首页，个人中心，学生管理，班委管理，班会组织管理，健康档案管理，党员发展管理，党员培训管理，学生成绩管理。主要技术：Java,Spring,mybatis,mysql,jquery,html。班委账号功能包括：系统首页，学生管理，学生成绩管理，活动信息管理，班费通知管理。服务器：SpringBoot自带 apache tomcat。JDK版本：Java JDK1.8。数据库可视化工具： navicat。数据库版本： mysql5.7。开发系统：Windows。
JavaWeb合集05-SpringBoot基础知识
qq_57340195的博客
10-17 872
Autowrite ：自动装配，通过声明的数据类型来装配对应的bean对象。缺点，只能获取到一个相同类型的bean对象，如果有IOC容器里面有2个Bean对象，使用@Autowrite依赖注入就好报错。由于三层架构中，每一层都需要下次成来提供对应的方法，所有要new 下一次的对象，如果上一层的类名发送改变，那么上一层就需要修改对应的类名，如下。3、@Resource注解：通过它来代替@Autowrite注解，直接指定要注入的Bean对象，参数name的值就是要注入的Bean对象。
确保Spring Boot定时任务只执行一次方案
2301_76419561的博客
10-14 602
确保Spring Boot定时任务只执行一次有多种方法，你可以根据实际需求选择最适合的方法。如果你需要更复杂的任务调度或周期性执行，@Scheduled注解和接口是更合适的选择。而对于一次性的初始化任务或应用程序启动任务，注解和实现接口则更为简洁明了。
Java设计模式之七大原则
06-01
Java设计模式的七大原则分别是： 1. 单一职责原则（Single Responsibility Principle，SRP）：一个类应该只负责一项职责，尽量做到类的内聚性高，耦合性低。 2. 开闭原则（Open Closed Principle，OCP）：对于扩展是开放的，而对于修改是关闭的，即在不修改原有代码的基础上实现新的功能。 3. 里氏替换原则（Liskov Substitution Principle，LSP）：子类可以替换父类并且不影响程序的正确性。 4. 接口隔离原则（Interface Segregation Principle，ISP）：不应该强迫客户端实现它们用不到的方法，即接口要尽量小、单一。 5. 依赖倒置原则（Dependency Inversion Principle，DIP）：高层模块不应该依赖低层模块，而是应该依赖其抽象。 6. 迪米特法则（Law of Demeter，LoD）：一个对象应该对其他对象保持最少的了解，即尽量减少对象之间的交互，减少耦合度。 7. 合成复用原则（Composite Reuse Principle，CRP）：尽量使用对象组合而不是继承来达到复用的目的。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值