【Android】浅析六大设计原则

【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 {@Overridepublic 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博客