再谈Java中的SOLID编程原则-CSDN博客

本文链接：https://blog.csdn.net/u013643074/article/details/131663661

SOLID是 Robert C. Martin 创建的一组五项原则，旨在帮助开发人员创建更易于维护、可扩展和适应性强的软件。

微信搜索关注《Java学研大本营》，加入读者群，分享更多精彩

在软件开发领域，创建易于理解、更改和重用的代码至关重要。随着软件系统变得越来越复杂，遵循既定原则和设计模式以确保代码可靠和可维护变得更加重要。这就是 SOLID 原则的用武之地！它们是 Robert C. Martin 创建的一组五项原则，旨在帮助开发人员创建更易于维护、可扩展和适应性强的软件。

SOLID 原则的缩写代表：

S —— 单一职责原则
O —— 开闭原则
L —— 里氏替换原则
I —— 接口隔离原则
D —— 依赖倒置原则

让我们更详细地探讨每个原则。

单一职责原则 (SRP)

一个类应该只有一个改变的理由。换句话说，一个类应该只有一个职责或工作。当一个类有多个职责时，维护和测试就变得很有挑战性。SRP 帮助我们避免上帝对象反模式，在这种模式中，一个类可以做所有事情。

假设有一个名为Customer. 这个类应该只负责存储和管理客户数据。它不应该负责发送电子邮件或创建发票。这些任务属于它们自己的类。

class Customer {
  private String name;
  private String email;
  private Address address;
  // getters and setters for name, email, and address
}

开闭原则 (OCP)

一个类应该对扩展开放，对修改关闭。这个原则意味着我们应该能够在不更改现有代码的情况下向系统添加新功能。这个原则通常是通过使用接口、抽象类和依赖注入来实现的。

假设有一个PaymentProcessor处理支付的类。现在，假设需要添加一种新的付款方式。PaymentProcessor可以扩展类并在其中添加新方法，而不是修改现有代码。

class PaymentProcessor {
  public void processPayment(Payment payment) {
    // process payment
  }
}
class CreditCardPaymentProcessor extends PaymentProcessor {
  public void processPayment(Payment payment) {
    // process credit card payment
  }
}
class PayPalPaymentProcessor extends PaymentProcessor {
  public void processPayment(Payment payment) {
    // process PayPal payment
  }
}

里氏替换原则 (LSP)

超类的对象应该能够被子类的对象替换而不影响程序的正确性。换句话说，类的任何子类都应该能够在不改变程序行为的情况下替换超类。

假设有一个名为 Animal的类，它有一个名为 makeSound()的方法。我们可以创建Animal的子类，例如Dog和Cat，它们也有一个makeSound()方法。应该能够在不改变程序行为的情况下用 Dog或 Cat 替换Animal。

class Animal {
  public void makeSound() {
    // make animal sound
  }
}
class Dog extends Animal {
  public void makeSound() {
    // make dog sound
  }
}
class Cat extends Animal {
  public void makeSound() {
    // make cat sound
  }
}

接口隔离原则（ISP）

不应强迫客户依赖于他们不使用的接口。也就是说，一个类应该只实现它需要的方法，而不是强制实现不必要的方法。这个原则有助于避免胖接口的问题和客户端实现他们不需要的方法的需要。

假设有两种类型的汽车：gasoline和electric。两者都有driving和 stopping的方法。然而，电动汽车也需要charged如此。为了解决这种差异，创建了一个ElectricCar带有附加charge方法的单独接口。

interface Car {
  void drive();
  void stop();
}
interface ElectricCar {
  void charge();
}

class GasolineCar implements Car {
  public void drive() {
    // drive gasoline car
  }
  public void stop() {
    // stop gasoline car
  }
}
class Tesla implements ElectricCar, Car {
  public void charge() {
    // charge electric car
  }
  public void drive() {
    // drive electric car
  }
  public void stop() {
    // stop electric car
  }
}

依赖倒置原则（DIP）

依赖倒置原则指出高层模块不应该依赖低层模块。两者都应该依赖于抽象。换句话说，一个类应该依赖于一个接口而不是一个具体的实现。这个原则有助于解耦类并使它们更易于测试和维护。

假设有一个Database处理数据库连接的类。可以创建一个类依赖的接口，DatabaseConnection而Database不是具体的实现。这使得将来更容易切换到不同的数据库。

Database下面是DIP 之后的类示例：

interface DatabaseConnection {
  Connection getConnection();
}

class Database {
  private DatabaseConnection databaseConnection;

  public Database(DatabaseConnection databaseConnection) {
    this.databaseConnection = databaseConnection;
  }

  public List<String> getUsers() {
    Connection connection = databaseConnection.getConnection();
    // retrieve users from the database using the connection
  }
}

class MySqlConnection implements DatabaseConnection {
  public Connection getConnection() {
    // return connection to MySQL database
  }
}

class OracleConnection implements DatabaseConnection {
  public Connection getConnection() {
    // return connection to Oracle database
  }
}