当前位置： 首页 > article >正文

【Android】浅析六大设计原则

article 2024/10/3 19:53:45

【Android】浅析六大设计原则

六大设计原则是软件开发中常用的设计原则，用来帮助开发者编写灵活、可维护、可扩展的代码。它们是面向对象设计（OOD）的核心，遵循这些原则能够避免代码中的常见问题，比如代码难以修改、难以扩展、难以维护等。

1. 单一职责原则（Single Responsibility Principle, SRP）

单一职责原则的核心思想是：一个类应该只有一个引起它变化的原因。换句话说，一个类应该只负责一项职责（即一个特定功能或行为），而不是承担多个职责。

一个类如果有多个职责，那么这些职责之间的耦合可能会让类变得难以维护。修改其中一个职责可能会影响另一个职责。单一职责原则的目的就是将不同的职责分离，使得每个类只承担一个职责，这样类的变化更为可控，代码更易于维护。

违反单一职责原则的常见问题：
  • 耦合过高：一个类承担多种职责时，这些职责会紧密耦合在一起。如果一个职责发生变化，可能会影响其他职责，导致系统中的多个模块被迫修改。
  • 难以维护：如果一个类有多个职责，随着时间的推移，代码会变得庞大且复杂，维护人员很难理解类的全部行为和目的。
  • 测试困难：单一职责原则下，每个类只负责一个功能，这样测试的复杂性较低。违反该原则的类则需要更复杂的测试，因为其内部包含多个不同的逻辑，需要更广泛的覆盖。
例子 1：员工类的职责划分

假设有一个Employee类，该类不仅负责员工的相关属性（如名字、薪水），还负责员工薪水计算、报告生成等其他职责。

class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public double calculateSalary() {
        // 计算薪水
        return salary;
    }

    public String generateReport() {
        // 生成员工报表
        return "Employee Report";
    }
}

在这个示例中，Employee类承担了两种职责：

  • 员工数据管理（如name和salary的管理）
  • 薪资计算和报表生成

这违反了单一职责原则，因为Employee类同时负责与员工数据和业务逻辑有关的内容。可以将薪资计算和报表生成职责从Employee类中分离出来。

改进后的设计：
class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public double getSalary() {
        return salary;
    }
}

class SalaryCalculator {
    public double calculateSalary(Employee employee) {
        // 计算薪水
        return employee.getSalary();
    }
}

class ReportGenerator {
    public String generateReport(Employee employee) {
        // 生成员工报表
        return "Report for " + employee;
    }
}

通过拆分Employee类，薪水计算和报表生成的职责被分别放在SalaryCalculator和ReportGenerator类中。这样，如果将来薪资计算逻辑改变，或报表格式修改，我们只需要调整相应的类，而不必修改Employee类。

如何判断类是否违反了单一职责原则？
  • 类是否处理多种逻辑：如果一个类处理了多个领域的逻辑，比如业务逻辑、UI展示、数据存储等，可能违反了单一职责原则。
  • 类是否有多个原因需要修改：如果一个类因为多个不同的原因（如需求变化、逻辑修改）而需要频繁修改，说明它可能承担了过多的职责。
  • 类的方法是否过多：如果一个类的方法众多，而且方法之间的关联度不高，也可能是该类承担了多种职责的表现。
单一职责原则的扩展：

有时候，我们会对类的职责范围进行扩展，尤其是在组件化的架构中。可以引入多个层次的职责划分，例如：

  • 业务逻辑层：负责具体的业务操作和数据处理
  • 数据访问层：负责数据库或文件系统等数据存储操作
  • 服务层：封装业务逻辑和数据访问之间的交互

通过分层架构，单一职责原则可以被严格地应用到每个层次的类上。

2. 开放-关闭原则（Open-Closed Principle, OCP）

开放-关闭原则的定义是：软件实体（如类、模块、函数等）应该对扩展开放，对修改关闭。这意味着当需求变化时，软件系统应该允许通过扩展来引入新的功能，而不需要修改现有的代码。

开放-关闭原则的目的是减少代码修改的风险，并提高代码的稳定性和可维护性。遵循这个原则，可以在保持现有代码功能完整性的前提下，通过增加新的功能模块来扩展系统，而无需对已有代码进行修改。这种方式有助于避免引入新的 bug，并且使系统更加灵活。

开放-关闭原则的基本思路：
  • 对扩展开放：可以在不修改现有代码的情况下，新增新功能。例如，通过添加新类或方法来扩展系统的行为。
  • 对修改关闭：不应该修改已有的代码，尤其是核心业务逻辑的实现。修改现有代码可能会影响已经稳定运行的功能，增加出错的风险。
如何实现开放-关闭原则：

开放-关闭原则通常依赖于多态性、继承和接口编程，而非依赖具体实现。通过使用抽象类、接口和设计模式（如工厂模式、策略模式等），我们可以有效地在不修改原有代码的基础上进行扩展。

示例：

class Rectangle {
    public void draw() {
        // 画矩形
    }
}

class Circle {
    public void draw() {
        // 画圆形
    }
}

class ShapeManager {
    public void drawShapes(List<Object> shapes) {
        for (Object shape : shapes) {
            if (shape instanceof Rectangle) {
                ((Rectangle) shape).draw();
            } else if (shape instanceof Circle) {
                ((Circle) shape).draw();
            }
        }
    }
}

该示例中，ShapeManager需要修改以支持新的形状。遵循开放-关闭原则的解决方案是通过多态实现，例如创建一个Shape接口，所有形状类都实现它。

开放-关闭原则的实际应用：
  • 扩展现有功能：当系统需要引入新功能时，尽量避免直接修改现有的类或方法，而是通过继承、实现接口或添加新的模块来扩展现有功能。这保证了现有功能的稳定性和健壮性。
  • 避免代码重复：通过遵循开放-关闭原则，可以避免在多个地方重复修改同样的代码。修改某个模块时，只需要扩展特定模块，而不需要在系统的其他部分重复相同的逻辑。
  • 减少回归风险：当我们修改现有代码时，可能会无意间破坏已有的功能。而通过扩展功能而不是修改原有代码，可以减少这些回归问题。

3. 里氏替换原则（Liskov Substitution Principle, LSP）

定义： 子类对象应该能够替换父类对象，并且程序逻辑不受影响。

解释： 子类应当能够在父类能使用的任何地方替换父类，并且不改变程序的正确性。遵循里氏替换原则可以确保继承体系的健壮性，避免由于子类实现不当导致的逻辑错误。

示例：

class Bird {
    public void fly() {
        // 鸟会飞
    }
}

class Ostrich extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("鸵鸟不会飞");
    }
}

在这个例子中，Ostrich类违背了里氏替换原则，因为它不应该继承Bird类。如果代码中使用了Bird类型，却遇到Ostrich时会抛出异常，这显然是有问题的设计。

4. 依赖倒置原则（Dependency Inversion Principle, DIP）

定义： 高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。

解释： 通过依赖于抽象（接口或抽象类）而不是具体实现，可以使得高层模块不必关心低层模块的具体实现细节，从而减少耦合，提高模块的灵活性和可扩展性。

示例：

class LightBulb {
    public void turnOn() {
        // 打开灯泡
    }
}

class Switch {
    private LightBulb lightBulb;
    
    public Switch(LightBulb lightBulb) {
        this.lightBulb = lightBulb;
    }
    
    public void operate() {
        lightBulb.turnOn();
    }
}

在此例中，Switch类依赖于具体的LightBulb类，违反了依赖倒置原则。我们可以通过引入抽象来改进：

interface Switchable {
    void turnOn();
}

class LightBulb implements Switchable {
    public void turnOn() {
        // 打开灯泡
    }
}

class Switch {
    private Switchable device;
    
    public Switch(Switchable device) {
        this.device = device;
    }
    
    public void operate() {
        device.turnOn();
    }
}

5. 接口隔离原则（Interface Segregation Principle, ISP）

定义： 不应该强迫用户依赖他们不需要的接口方法，接口应该尽量小而精。

解释： 大而全的接口会导致类实现一些无关的功能，而这些功能可能并不需要。通过将大接口拆分成多个小接口，类只需要实现其实际需要的功能接口，这样可以避免代码冗余，提高系统的灵活性和可维护性。

示例：

interface Worker {
    void work();
    void eat();
}

在这个示例中，Worker接口包含了work和eat方法，可能对于某些实现类来说并不需要eat功能。可以将接口拆分为更小的接口：

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

6. 迪米特法则（Law of Demeter, LoD）

迪米特法则，也称为最少知识原则（Principle of Least Knowledge），其核心思想是：一个对象应当尽可能少地了解其他对象的细节。具体来说，一个对象不应过多依赖于其他对象的内部结构和实现细节。对象之间的交互应该通过有限的、尽可能直接的接口进行，而不是通过一长串的调用链来操作多个对象的内部数据。

迪米特法则鼓励我们设计低耦合的系统。高耦合的系统会导致修改某个模块时不得不改动许多依赖模块，增加了系统复杂性和维护难度。通过限制对象之间的过度依赖，迪米特法则减少了耦合，提高了系统的灵活性和可维护性。

具体规则：

根据迪米特法则，一个对象只应与以下几种“朋友”通信：

  1. 自身：对象可以与自身的方法和属性交互。
  2. 成员对象：对象可以与直接包含的成员对象交互。
  3. 方法参数：对象可以与方法参数交互。
  4. 创建的对象：对象可以与它自己创建的对象交互。
  5. 全局变量或单例对象：在某些设计中，对象可以与全局对象或单例对象交互（但应当谨慎使用）。

示例：

class Customer {
    public Wallet getWallet() {
        return new Wallet();
    }
}

class Wallet {
    public void deductAmount(int amount) {
        // 扣款
    }
}

class Store {
    public void processPayment(Customer customer, int amount) {
        customer.getWallet().deductAmount(amount);
    }
}

这里Store类直接依赖于Customer的Wallet类，违反了迪米特法则。更好的做法是通过Customer提供一个支付方法，而不暴露内部的Wallet：

class Customer {
    private Wallet wallet;

    public void pay(int amount) {
        wallet.deductAmount(amount);
    }
}

class Store {
    public void processPayment(Customer customer, int amount) {
        customer.pay(amount);
    }
}

结语

参考：

设计模式之六大设计原则-CSDN博客

【设计模式】六大设计原则_设计模式6大准则-CSDN博客


http://www.kler.cn/news/330726.html

相关文章：

  • C++中的类型推导：auto 和 decltype 介绍
  • 如何理解矩阵的复数特征值和特征向量？
  • 【60天备战2024年11月软考高级系统架构设计师——第35天：系统安全设计——安全设计模式】
  • quiz: python网络爬虫之规则1
  • 【H2O2|全栈】关于CSS（8）CSS3扩充了哪些新鲜的东西？
  • ISP下载，IAP,ICP,USB转TTL下载SWIM、DAP-link、CMSIS-DAP、ST-LINK，SPI（通信方式）,
  • 计算机视觉学习--目标检测Java开发案例
  • 【ios】---swift开发从入门到放弃
  • 【AIGC】AI时代的数据安全：使用ChatGPT时的自查要点
  • 【MySQL 07】内置函数
  • Pikachu-Sql Inject-搜索型注入
  • Python对数据库（MySQL，redis、MongoDB）的操作
  • 24.2.29蓝桥杯|单位换算--8道题
  • 【4.7】图搜索算法-DFS和BFS解根到叶子节点数字之和
  • Linux中的软硬链接和动静态库
  • 大模型压缩3种方式；模型大小的计算；知识蒸馏：利用教师的输入输出，训练调整学生的小模型
  • Linux 中的 Makefile 伪目标详解
  • 【Spring Boot 入门三】Spring Boot与数据库集成 - 构建数据驱动的应用
  • 版本控制-git
  • uniapp中检测应用更新的两种方式-升级中心之uni-upgrade-center-app