OOD五大原则SOLID总览
SOLID 是面向对象设计的五大基本原则的首字母缩写，旨在帮助开发者编写更清晰、灵活和易于维护的代码。
它们有助于设计可扩展和可维护的系统，特别是在复杂的项目中应用非常广泛。
详解介绍见链接：
以下是五大 SOLID 原则的简单介绍：
1. 单一职责原则 (Single Responsibility Principle, SRP)
定义：
每个类应该只有一个职责，即只做一件事。简单来说，一个类应该只有一个引起其变化的原因。
目的：
- 降低类的复杂度。
- 提高类的可读性和可维护性。
- 使代码更容易修改，减少因为一个改动影响到不相关的功能。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class User {
private String name;
private String email;
public void updateName(String name) {
this.name = name;
}
public void updateEmail(String email) {
this.email = email;
}
}
class EmailService {
public void sendEmail(String email, String message) {
System.out.println("Sending email to " + email + ": " + message);
}
}
|
User 类只负责用户信息的处理，而 EmailService 类负责邮件发送，符合单一职责原则。
2. 开放封闭原则 (Open-Closed Principle, OCP)
定义：
软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。也就是说，当需求变更时，应该通过扩展功能来满足需求，而不是通过修改已有的代码。
目的：
- 提高系统的可扩展性。
- 减少对已有代码的影响，避免引入新的错误。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
abstract class Shape {
public abstract double area();
}
class Circle extends Shape {
private double radius;
public Circle(double radius) {
this.radius = radius;
}
@Override
public double area() {
return Math.PI * radius * radius;
}
}
class Rectangle extends Shape {
private double width, height;
public Rectangle(double width, double height) {
this.width = width;
this.height = height;
}
@Override
public double area() {
return width * height;
}
}
|
在这个例子中，如果需要支持更多形状，比如三角形，只需新增一个类来继承 Shape，而不需要修改已有的 Circle 或 Rectangle 类，符合开放封闭原则。
3. 里氏替换原则 (Liskov Substitution Principle, LSP)
定义：
子类必须能够替换其父类，并且保证程序的行为不变。也就是说，在使用父类对象的地方，都可以安全地替换为子类对象，而不会引发问题。
目的：
- 保证类的继承结构是合理的，子类真正符合父类的行为契约。
- 提高代码的健壮性和扩展性。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| class Bird {
public void fly() {
System.out.println("Flying...");
}
}
class Sparrow extends Bird {}
class Ostrich extends Bird {
@Override
public void fly() {
throw new UnsupportedOperationException("Ostriches can't fly");
}
}
|
在这个例子中，Ostrich（鸵鸟）不能替换 Bird，因为鸵鸟不能飞，违反了 LSP。解决方法是重构继承关系，把不能飞的鸟类单独处理。
4. 接口隔离原则 (Interface Segregation Principle, ISP)
定义：
客户端不应该被迫依赖它们不使用的方法。即应将大接口拆分成多个小接口，每个接口应只包含特定的行为，从而避免实现类去依赖不需要的方法。
目的：
- 避免接口臃肿，确保类只实现其需要的方法。
- 提高代码的灵活性和可维护性。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| interface Animal {
void eat();
void fly();
}
class Dog implements Animal {
@Override
public void eat() {
System.out.println("Dog eats");
}
@Override
public void fly() {
}
}
interface Eater {
void eat();
}
interface Flyer {
void fly();
}
class Dog implements Eater {
@Override
public void eat() {
System.out.println("Dog eats");
}
}
|
这里将 Animal 拆分为 Eater 和 Flyer 两个独立接口，避免了不必要的依赖，符合接口隔离原则。
5. 依赖倒置原则 (Dependency Inversion Principle, DIP)
定义：
高层模块不应该依赖低层模块，二者都应该依赖于抽象（接口或抽象类）。即，具体的实现类应该依赖于接口或抽象类，而不是高层模块直接依赖实现细节。
目的：
- 降低模块之间的耦合性，使得系统更灵活、更容易扩展和维护。
- 通过依赖于接口或抽象类，避免高层模块与低层实现的强依赖关系。
示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| interface PaymentMethod {
void pay(double amount);
}
class CreditCard implements PaymentMethod {
@Override
public void pay(double amount) {
System.out.println("Paid with Credit Card: " + amount);
}
}
class PaymentProcessor {
private PaymentMethod paymentMethod;
public PaymentProcessor(PaymentMethod paymentMethod) {
this.paymentMethod = paymentMethod;
}
public void processPayment(double amount) {
paymentMethod.pay(amount);
}
}
public class Main {
public static void main(String[] args) {
PaymentMethod paymentMethod = new CreditCard();
PaymentProcessor processor = new PaymentProcessor(paymentMethod);
processor.processPayment(100.0);
}
}
|
在这个例子中，PaymentProcessor 依赖于抽象的 PaymentMethod 接口，而不是具体的 CreditCard 实现类。通过这种方式，可以轻松替换不同的支付方式，而不需要修改 PaymentProcessor，符合依赖倒置原则。
总结：
- **SRP (单一职责原则)**：每个类应该只有一个职责。
- **OCP (开放封闭原则)**：对扩展开放，对修改关闭。
- **LSP (里氏替换原则)**：子类可以替换父类，且不会影响程序行为。
- **ISP (接口隔离原则)**：为不同客户端提供专门的接口，而不应该强迫它们依赖不需要的功能。
- **DIP (依赖倒置原则)**：高层模块依赖于抽象，而非具体实现。
这五大 SOLID 原则帮助开发者设计出更灵活、可扩展、可维护的系统，并确保在需求变更时可以通过扩展系统而非修改现有代码来满足新的需求。
