什么是 SOLID 原则？（五项面向对象设计 SOLID 原则）

SOLID 原则是由 Robert C. Martin 提出的五项基本面向对象设计（OOD）原则。

SOLID 原则为构建软件提供了指导方针，使软件在项目不断发展时更易于维护和扩展。这些原则有助于消除代码坏味道、简化代码重构，并支持敏捷或自适应开发实践。

本指南将逐一介绍每项原则，说明它们如何提升您的开发技能，并帮助您编写更好、更健壮的 Java 代码。

什么是 SOLID 原则？

SOLID 这个缩写代表：

• S：单一职责原则（Single Responsibility Principle）
• O：开闭原则（Open-Closed Principle）
• L：里氏替换原则（Liskov Substitution Principle）
• I：接口隔离原则（Interface Segregation Principle）
• D：依赖倒置原则（Dependency Inversion Principle）

单一职责原则

单一职责原则是指每个类应只专注于一项特定的任务或目的，确保它只有一个被修改的理由。

从技术角度讲，一个类的设计应只受一种类型的变化影响，例如数据库逻辑或日志逻辑。举例来说，如果一个类表示 Book 或 Student 这样的数据实体，那么只有当该实体的结构或属性发生变化时，才应对其进行更新。

遵循这一原则有显著的好处。它降低了多个团队出于不相关目的修改同一个类的风险，否则可能导致相互冲突或不兼容的更改。

此外，它还简化了版本控制。例如，如果一个专门负责数据库操作的类被更新，我们可以轻松识别出与数据库功能相关的更改。

这一原则还能减少协作开发中的合并冲突。确保每个类只有单一目的，重叠的更改就会更少，冲突也会更少发生、更容易解决。

示例

下面通过一个示例演示单一职责原则。我们来看一个 Student 类：

在应用 SRP（单一职责原则）之前，Student 类既处理学生相关的职责，又处理通知相关的职责，这违反了 SRP。

public class Student {
public String getDetails(int studentID) { 
// Logic to fetch student details
}
public void updateGrade(int studentID, int grade) { 
// Logic to update student grade
}
public void sendNotification(String message) { 
// Logic to send notifications to the student
}
}

应用单一职责原则后，我们将通知职责拆分到一个新的 NotificationService 类中：

public class Student {
public String getDetails(int studentID) { 
// Logic to fetch student details
}
public void updateGrade(int studentID, int grade) { 
// Logic to update student grade
}
}
public class NotificationService {
public void sendNotification(String message) { 
// Logic to send notifications to students
}
}

Student 类现在只专注于与学生相关的行为。

通知逻辑被封装在 NotificationService 类中，使代码更易于管理和修改。

每个类都有清晰且单一的职责，从而降低耦合，提高可维护性。

开闭原则

开闭原则指出：“软件实体（如类、模块或函数）应当对扩展开放，对修改关闭。”这意味着您可以在不修改现有代码的情况下为系统添加新功能。

通过示例理解这一原则

假设在一个几何应用中，您有一个用于计算不同形状面积的 Shape 类。最初，该类只支持计算矩形的面积。后来，您希望添加对圆形面积计算的支持。

与其修改现有的 Shape 类来加入圆形的逻辑，不如创建一个新类，例如 Circle，来扩展其行为。这样 Shape 类保持不变，同时又能添加新功能。

实现方式如下：

// Base class
public abstract class Shape {
public abstract double calculateArea();
}
// Rectangle class
public class Rectangle extends Shape {
private double length;
private double width;
public Rectangle(double length, double width) {
this.length = length;
this.width = width;
}
@Override
public double calculateArea() {
return length * width;
}
}
// Circle class
public class Circle extends Shape {
private double radius;
public Circle(double radius) {
this.radius = radius;
}
@Override
public double calculateArea() {
return Math.PI * radius * radius;
}
}

在上述代码中，根据开闭原则：

Shape 类没有被修改，从而保证了现有代码的稳定性。通过继承 Shape 类，可以轻松添加新的形状（如 Triangle 或 Square）。这种方法提升了代码的可复用性、灵活性和可维护性。

里氏替换原则

里氏替换原则由 Barbara Liskov 于 1987 年提出，其内容是“子类型必须能够替换其基类型。”这意味着任何子类都应能够替换其父类，而不会引起意外行为。

为了理解这一原则，我们以 Bird 类为例。Bird 通常具有飞行等行为。某种特定的鸟，例如 Penguin（企鹅），可以继承 Bird 类。然而，企鹅不会飞，如果直接继承飞行行为，就会违反里氏替换原则。

示例

下面用代码来说明：

以下是违反里氏替换原则的示例：

// Parent class
public class Bird {
public void fly() {
System.out.println("Flying...");
}
}
// Child class
public class Penguin extends Bird {
@Override
public void fly() {
throw new UnsupportedOperationException("Penguins can't fly");
}
}

在这个例子中，用 Penguin 替换 Bird 会导致意外行为，因为 Penguin 类用一个异常重写了 fly 方法。

为了应用里氏替换原则，我们可以重构代码，将飞行行为分离到另一个抽象中：

// Base class
public abstract class Bird {
public abstract void eat();
}
// Flying behavior
public interface Flyable {
void fly();
}
// Subclass for birds that can fly
public class Sparrow extends Bird implements Flyable {
@Override
public void eat() {
System.out.println("Sparrow is eating...");
}
@Override
public void fly() {
System.out.println("Sparrow is flying...");
}
}
// Subclass for birds that cannot fly
public class Penguin extends Bird {
@Override
public void eat() {
System.out.println("Penguin is eating...");
}
}

Bird 类现在只专注于进食等共有行为。

飞行行为被单独隔离，只有会飞的鸟才实现 Flyable 接口。

用任何一种鸟替换 Bird 类都能按预期工作，保持了一致性并避免了运行时错误。

上述代码示例确保子类可以替换其父类，而不会违反里氏替换原则。

接口隔离原则

接口隔离原则关注的是接口而不是类，它与单一职责原则密切相关。其内容是：“不应强迫任何客户端实现它不使用的接口。”

其核心思想是避免创建庞大、通用的接口，而是将其拆分为更小、更具体的接口，以满足各个客户端的需求。

简单来说，按照接口隔离原则，一个类或实体只需实现与其特定用途相关的方法。这减少了不必要的依赖，并保证了设计的灵活性。

示例

设想一个图书馆管理系统。其中有一个通用接口 LibraryServices，包含借书、还书、支付滞纳金和预约电子书的方法。

现在，假设有两类用户：到馆读者和在线用户。

到馆读者只需要借书和还书功能。

在线用户则专注于预约电子书，可能不会使用借书或还书服务。

为这两类用户使用同一个 LibraryServices 接口，会迫使双方都实现自己不需要的方法，从而违反接口隔离原则。

违反接口隔离原则的示例

// Fat interface with unrelated methods
public interface LibraryServices {
void borrowBook();
void returnBook();
void payLateFee();
void reserveEBook();
}
// In-person visitor implements all methods but uses only a few
public class InPersonVisitor implements LibraryServices {
@Override
public void borrowBook() {
System.out.println("Borrowing a book...");
}
@Override
public void returnBook() {
System.out.println("Returning a book...");
}
@Override
public void payLateFee() {
System.out.println("Paying a late fee...");
}
@Override
public void reserveEBook() {
// Not applicable for in-person visitors
throw new UnsupportedOperationException("Not applicable for in-person visitors");
}
}

遵循接口隔离原则，将单一的大接口拆分为更小的、面向特定客户端的接口。

// Smaller, focused interfaces
public interface BookBorrowing {
void borrowBook();
void returnBook();
}
public interface FeePayment {
void payLateFee();
}
public interface EBookReservation {
void reserveEBook();
}
// In-person visitors only implement relevant interfaces
public class InPersonVisitor implements BookBorrowing, FeePayment {
@Override
public void borrowBook() {
System.out.println("Borrowing a book...");
}
@Override
public void returnBook() {
System.out.println("Returning a book...");
}
@Override
public void payLateFee() {
System.out.println("Paying a late fee...");
}
}
// Online users implement only their relevant interface
public class OnlineUser implements EBookReservation {
@Override
public void reserveEBook() {
System.out.println("Reserving an e-book...");
}
}

上述方法确保设计保持简洁，并遵循接口隔离原则。

遵循该原则的好处

• 每个客户端只与其相关的接口打交道。
• 减少不必要的依赖。
• 使系统更易于维护和扩展。
• 避免潜在的运行时错误，例如未实现的方法抛出异常。

依赖倒置原则

依赖倒置原则强调：

“实体应依赖于抽象，而不是具体实现。”

这意味着高层模块（负责整体功能）不应直接依赖低层模块（负责实现细节）。相反，二者都应依赖于抽象（如接口或抽象类）。

遵循这一原则，您可以实现解耦，使系统更灵活、更易维护，并且在修改时不会影响其他组件。

示例

设想一个 NotificationService 需要通过短信和电子邮件等不同渠道发送消息。如果 NotificationService 直接依赖短信或邮件发送的具体类，它就会与这些实现紧密耦合。低层类的任何变化（例如添加 WhatsApp 通知）都需要修改 NotificationService，从而违反该原则。

// High-level module directly depends on low-level modules
public class NotificationService {
private EmailSender emailSender;
private SMSSender smsSender;
public NotificationService() {
this.emailSender = new EmailSender(); // Tight coupling
this.smsSender = new SMSSender(); // Tight coupling
}
public void sendNotification(String message) {
emailSender.sendEmail(message);
smsSender.sendSMS(message);
}
}
class EmailSender {
public void sendEmail(String message) {
System.out.println("Sending Email: " + message);
}
}
class SMSSender {
public void sendSMS(String message) {
System.out.println("Sending SMS: " + message);
}
}

在这个例子中，NotificationService 与 EmailSender 和 SMSSender 都紧密耦合。添加新的通知方式（例如 WhatsAppSender）就需要修改 NotificationService 类，这违反了依赖倒置原则。

为了遵循依赖倒置原则，需要引入一个抽象（接口），让高层模块（NotificationService）和低层模块（EmailSender、SMSSender）都依赖于它。

// Abstraction for sending notifications
public interface NotificationSender {
void send(String message);
}
// Low-level module: EmailSender
public class EmailSender implements NotificationSender {
@Override
public void send(String message) {
System.out.println("Sending Email: " + message);
}
}
// Low-level module: SMSSender
public class SMSSender implements NotificationSender {
@Override
public void send(String message) {
System.out.println("Sending SMS: " + message);
}
}
// High-level module: NotificationService
public class NotificationService {
private final NotificationSender notificationSender;
// Dependency injection via constructor
public NotificationService(NotificationSender notificationSender) {
this.notificationSender = notificationSender;
}
public void sendNotification(String message) {
notificationSender.send(message);
}
}

使用示例

现在，NotificationService 可以与 NotificationSender 接口的任何实现配合使用，而无需直接依赖特定的类。

public class Main {
public static void main(String[] args) {
NotificationSender emailSender = new EmailSender();
NotificationService emailService = new NotificationService(emailSender);
emailService.sendNotification("Your email message!");
NotificationSender smsSender = new SMSSender();
NotificationService smsService = new NotificationService(smsSender);
smsService.sendNotification("Your SMS message!");
}
}

依赖倒置原则的好处

• 降低高层模块与低层模块之间的耦合。
• 便于在不修改现有代码的情况下添加新的实现（例如 WhatsAppSender）。
• 鼓励使用依赖注入，从而简化测试并提高灵活性。

通过依赖抽象而不是具体实现，您可以构建模块化、可扩展的系统。

总结

本文探讨了编写整洁、可维护代码的五项 SOLID 原则。遵循这些原则，项目将更易于与团队成员共享、扩展新功能、修改、测试和重构，同时将潜在的问题降到最低。

您在寻找优质的 VPS 主机服务吗？BlueVPS 提供强大、可扩展且可定制的主机解决方案，配备独享环境和不限流量。立即开始，让您的主机体验更上一层楼！