【前端】浅谈SOLID原则在前端的使用

原创 宁 奇舞精选

本文作者系360奇舞团前端开发工程师

简介

SOLID 原则是由 Robert C. Martin 在 2000 年提出的一套软件开发准则，最初用于面向对象编程（OOP），旨在解决软件开发中的复杂性和维护问题。随着时间推移，它不仅在传统 OOP 语言中广泛应用，也被引入到 JavaScript 和 TypeScript 等现代编程语言和框架中，如 React 和 Angular。

SOLID 原则包括以下五个方面：

单一职责原则（Single Responsibility Principle - SRP）开闭原则（Open/Closed Principle - OCP）里氏替换原则（Liskov Substitution Principle - LSP）接口隔离原则（Interface Segregation Principle - ISP）依赖倒置原则（Dependency Inversion Principle - DIP）

在 JavaScript 和 TypeScript 中，尽管它们是动态语言且不以类为核心，但这些原则可融入组件化和模块化架构，开发者能借此确保代码简洁、可扩展、易维护和测试

一、 单一职责原则 (SRP)

原则

一个类或模块应只有一个发生变化的原因，仅负责一项特定功能。在前端开发中，尤其是在 React 等组件化框架中，我们经常会看到组件承担了太多职责——不仅负责 UI 渲染，还处理业务逻辑和数据请求。这种情况很容易导致代码难以维护和测试，违反了 SRP 原则。

反例(js-react)

function UserProfile({ userId }) {const [user, setUser] = useState(null);useEffect(() => {fetchUserData();}, [userId]);async function fetchUserData() {const response = await fetch(`/api/users/${userId}`);const data = await response.json();setUser(data);}return <div>{user?.name}</div>;
}

此例中，UserProfile 组件既负责 UI 渲染又负责数据获取，违反 SRP 原则，当修改数据获取或界面渲染逻辑时，可能影响组件其他部分，增加维护复杂性。

重构后代码

为了遵循 SRP 原则，我们可以将数据获取逻辑提取到一个自定义的Hook中，让组件 UserProfile 只关注 UI 渲染。

// 自定义 Hook 用于获取用户数据
function useUserData(userId) {const [user, setUser] = useState(null);useEffect(() => {async function fetchUserData() {const response = await fetch(`/api/users/${userId}`);const data = await response.json();setUser(data);}fetchUserData();}, [userId]);return user;
}
// UI 组件
function UserProfile({ userId }) {const user = useUserData(userId); // 将数据获取逻辑移到了 Hook 中return <div>{user?.name}</div>;
}

通过自定义 Hook（useUserData）将数据获取逻辑与 UI 逻辑分离，符合 SRP 原则，提升了代码的可维护性和复用性。

反例(ts-angular)

反例:

@Injectable()
export class UserService {constructor(private http: HttpClient) {}getUser(userId: string) {return this.http.get(`/api/users/${userId}`);}updateUserProfile(userId: string, data: any) {// 更新用户信息并处理通知return this.http.put(`/api/users/${userId}`, data).subscribe(() => {console.log('User updated');alert('Profile updated successfully');});}
}

UserService 类承担多个职责，包括获取和更新用户信息以及处理通知，违背 SRP 原则，导致维护困难。

重构后代码

@Injectable()
export class UserService {constructor(private http: HttpClient) {}getUser(userId: string) {return this.http.get(`/api/users/${userId}`);}updateUserProfile(userId: string, data: any) {return this.http.put(`/api/users/${userId}`, data);}
}// 独立的通知服务
@Injectable()
export class NotificationService {notify(message: string) {alert(message);}
}

通过将通知逻辑分离到一个独立的 NotificationService 中，我们遵循了 单一职责原则（SRP），将通知逻辑分离到 NotificationService 中，遵循 SRP 原则，每个类职责明确，带来诸多好处：

职责明确，增强可维护性。修改通知方式只需更改 NotificationService，不影响用户服务其他功能。提高复用性。NotificationService 可在其他服务或组件中复用。测试更加方便。可单独为 UserService 和 NotificationService 编写测试。代码扩展更加灵活。如需更改通知方式，只需修改或扩展 NotificationService。

// **职责明确，增强可维护性：**修改通知为弹出窗口通知
@Injectable()
export class NotificationService {notify(message: string) {showModal(message);  // 假设我们有一个 showModal 函数用于展示弹窗}
}// 提高复用性。NotificationService 可在其他服务或组件中复用
@Injectable()
export class OrderService {constructor(private notificationService: NotificationService) {}placeOrder(orderData: any) {// 订单处理逻辑this.notificationService.notify('Order placed successfully');}
}// 测试更加方便。可单独为 UserService 和 NotificationService 编写测试。
it('should fetch user data', () => {const userService = new UserService(httpClientMock);userService.getUser('1').subscribe(data => {expect(data).toEqual(mockUserData);});
});
// NotificationService 测试
it('should notify the user', () => {const notificationService = new NotificationService();spyOn(window, 'alert');notificationService.notify('Test message');expect(window.alert).toHaveBeenCalledWith('Test message');
});//代码扩展更加灵活。如需更改通知方式，只需修改或扩展 NotificationService
@Injectable()
export class EmailNotificationService extends NotificationService {notify(message: string) {sendEmail(message);  // 假设我们有一个 sendEmail 函数发送邮件}
}

二、开闭原则（OCP）

原则

软件实体应能在不修改模块源代码的情况下扩展其行为，即对扩展开放，对修改封闭。

反例(js-react)

假设我们有一个表单验证函数，它目前工作正常，但未来可能需要添加更多的验证逻辑。

function validateForm(values) {let errors = {};if (!values.name) {errors.name = "Name is required";}if (!values.email) {errors.email = "Email is required";} else if (!/\S+@\S+\.\S+/.test(values.email)) {errors.email = "Email is invalid";}return errors;
}

validateForm 函数包含所有验证逻辑，添加新验证规则需修改现有代码，违背 OCP 原则，增加维护难度和出错风险。

重构后代码

// 基础验证器接口
class Validator {validate(value) {throw new Error("validate method must be implemented");}
}
// 具体的验证器
class RequiredValidator extends Validator {validate(value) {return value ? null : "This field is required";}
}
class EmailValidator extends Validator {validate(value) {return /\S+@\S+\.\S+/.test(value) ? null : "Email is invalid";}
}
// 验证表单函数
function validateForm(values, validators) {let errors = {};for (let field in validators) {const error = validators[field].validate(values[field]);if (error) {errors[field] = error;}}return errors;
}
// 使用示例
const validators = {name: new RequiredValidator(),email: new EmailValidator(),
};
const errors = validateForm({ name: "", email: "invalid email" }, validators);
console.log(errors);

通过将验证逻辑封装到独立的类（如 RequiredValidator 和 EmailValidator）中，我们使得验证器符合 开放/封闭原则（OCP）。现在，如果需要添加新的验证规则（例如电话号码验证），只需创建一个新的验证器类，而无需修改现有的验证逻辑；换句话说，应该允许在不修改现有核心代码的情况下添加新功能。

反例(ts-angular)

在 Angular 中，服务和组件的设计应允许添加新功能，而无需修改核心逻辑。

export class NotificationService {send(type: 'email' | 'sms', message: string) {if (type === 'email') {// 发送电子邮件} else if (type === 'sms') {// 发送短信}}
}

在这个例子中，NotificationService 类违反了 开放/封闭原则（OCP），因为每次需要支持新类型的通知（例如推送通知）时，必须修改 send 方法。这不仅会增加维护成本，还容易引发错误，尤其是当代码变得越来越复杂时。

重构后代码

interface Notification {send(message: string): void;
}@Injectable()
export class EmailNotification implements Notification {send(message: string) {// 发送电子邮件的逻辑}
}@Injectable()
export class SMSNotification implements Notification {send(message: string) {// 发送短信的逻辑}
}@Injectable()
export class NotificationService {constructor(private notifications: Notification[]) {}notify(message: string) {this.notifications.forEach(n => n.send(message));}
}

通过将通知发送逻辑封装到各自独立的类（EmailNotification 和 SMSNotification）中，我们实现了符合 开放/封闭原则（OCP） 的设计。这个设计的核心思想是，所有新功能（例如新的通知类型）都可以通过创建新的类来扩展，而不需要修改现有的 NotificationService 类。好处：对扩展开放，对修改封闭、提高复用性、测试更加简单、增强代码的灵活性与维护性。

三、 里氏替换原则 (LSP)

原则

子类型必须可以替换其基类型。派生类或组件应该能够替换基类，而不会影响程序的正确性。

反例(js-react)

当使用高阶组件 (HOC) 或有条件地渲染不同组件时，LSP 有助于确保所有组件的行为都可预测。

反向例子:

function Button({ onClick }) {return <button onClick={onClick}>Click me</button>;
}
function LinkButton({ href }) {return <a href={href}>Click me</a>;
}
<Button onClick={() => {}} />;
<LinkButton href="/home" />;

这里Button和LinkButton不一致，一个用onClick，一个用href，替换起来比较困难。

重构后代码

function Clickable({ children, onClick }) {return <div onClick={onClick}>{children}</div>;
}function Button({ onClick }) {return <Clickable onClick={onClick}><button>Click me</button></Clickable>;
}function LinkButton({ href }) {return <Clickable onClick={() => window.location.href = href}><a href={href}>Click me</a></Clickable>;
}

现在，Button 和 LinkButton 的行为类似，均遵循 LSP。

反例(ts-angular)

class Rectangle {constructor(protected width: number, protected height: number) {}area() {return this.width * this.height;}
}
class Square extends Rectangle {constructor(size: number) {super(size, size);}setWidth(width: number) {this.width = width;this.height = width; // Breaks LSP}
}

修改 Square 中的 setWidth 违反了 LSP，因为 Square 的行为与 Rectangle 不同。

重构后代码

class Shape {area(): number {throw new Error('Method not implemented');}
}class Rectangle extends Shape {constructor(private width: number, private height: number) {super();}area() {return this.width * this.height;}
}class Square extends Shape {constructor(private size: number) {super();}area() {return this.size * this.size;}
}

现在，Square和Rectangle可以相互替代而不违反 LSP。

四、接口隔离原则 (ISP)

原则

客户端不应被迫依赖他们不使用的接口

反例(js-react)

React 组件有时会收到不必要的 props，导致代码紧密耦合且庞大。

function MultiPurposeComponent({ user, posts, comments }) {return (<div><UserProfile user={user} /><UserPosts posts={posts} /><UserComments comments={comments} /></div>);
}

这里，组件依赖于多个 props，即使它可能并不总是使用它们。

重构后代码

function UserProfileComponent({ user }) {return <UserProfile user={user} />;
}function UserPostsComponent({ posts }) {return <UserPosts posts={posts} />;
}function UserCommentsComponent({ comments }) {return <UserComments comments={comments} />;
}

通过将组件拆分成更小的组件，每个组件仅依赖于它实际使用的数据。

反例(ts-angular)

interface Worker {work(): void;eat(): void;
}class HumanWorker implements Worker {work() {console.log('Working');}eat() {console.log('Eating');}
}class RobotWorker implements Worker {work() {console.log('Working');}eat() {throw new Error('Robots do not eat'); // Violates ISP}
}

这里，RobotWorker被迫实现了不相关的eat方法。

重构后代码

interface Worker {work(): void;
}
interface Eater {eat(): void;
}
class HumanWorker implements Worker, Eater {work() {console.log('Working');}eat() {console.log('Eating');}
}
class RobotWorker implements Worker {work() {console.log('Working');}
}

通过分离 Worker 和 Eater 接口，我们确保客户端只依赖于它们所需要的。

五、依赖倒置原则 (DIP)

原则

高级模块不应依赖于低级模块。两者都应依赖于抽象（例如接口）。

反例(js-react)

function fetchUser(userId) {return fetch(`/api/users/${userId}`).then(res => res.json());
}function UserComponent({ userId }) {const [user, setUser] = useState(null);useEffect(() => {fetchUser(userId).then(setUser);}, [userId]);return <div>{user?.name}</div>;
}

这里，UserComponent 与 fetchUser 函数紧密耦合。

重构后代码

function UserComponent({ userId, fetchUserData }) {const [user, setUser] = useState(null);useEffect(() => {fetchUserData(userId).then(setUser);}, [userId, fetchUserData]);return <div>{user?.name}</div>;
}// Usage
<UserComponent userId={1} fetchUserData={fetchUser} />;

通过将 fetchUserData 注入组件，我们可以轻松地交换实现以进行测试或用于不同的用例。

反例(ts-angular)

@Injectable()
export class UserService {constructor(private http: HttpClient) {}getUser(userId: string) {return this.http.get(`/api/users/${userId}`);}
}@Injectable()
export class UserComponent {constructor(private userService: UserService) {}loadUser(userId: string) {this.userService.getUser(userId).subscribe(user => console.log(user));}
}

UserComponent 与 UserService 紧密耦合，因此很难替换掉 UserService。

重构后代码

interface UserService {getUser(userId: string): Observable<User>;
}@Injectable()
export class ApiUserService implements UserService {constructor(private http: HttpClient) {}getUser(userId: string) {return this.http.get<User>(`/api/users/${userId}`);}
}
@Injectable()
export class UserComponent {constructor(private userService: UserService) {}loadUser(userId: string) {this.userService.getUser(userId).subscribe(user => console.log(user));}
}

通过依赖接口（UserService），UserComponent 现在与 ApiUserService 的具体实现分离。

结论

无论是前端的 React、Angular 等框架，还是后端的 Node.js，SOLID 原则都能作为指南，让软件架构更加稳固。SOLID 原则能非常有效地确保代码干净、可维护且可扩展，在 JavaScript 和 TypeScript 框架（如 React 和 Angular）中同样如此。应用这些原则，开发人员能编写灵活且可重复使用的代码，随着需求的发展，这些代码也能轻松扩展和重构。遵循 SOLID 原则，能让代码库变得强大，为未来的增长做好准备。

关于奇舞团

奇舞团是 360 集团最大的大前端团队，非常重视人才培养，有工程师、讲师、翻译官、业务接口人、团队 Leader 等多种发展方向供员工选择，并辅以提供相应的技术力、专业力、通用力、领导力等培训课程。奇舞团以开放和求贤的心态欢迎各种优秀人才关注和加入奇舞团。

参考🔗

https://mp.weixin.qq.com/s/d2Ig_SvjLvPmNK-6BFrdsA