SOLID 原则在前端的应用

SOLID 是面向对象编程（OOP）的五大设计原则，由罗伯特·马丁（Robert C. Martin）提出，旨在提高代码的可维护性、可扩展性和可读性。这些原则不仅适用于后端开发，在前端（尤其是组件化、模块化开发中）同样具有重要指导意义。

定义：一个类/模块/组件应该只负责一项职责，只有一个引起它变化的原因。 前端表现：

组件拆分 ：一个组件只做一件事。例如，避免在一个 UserCard 组件中同时处理用户信息展示、表单提交和权限验证，应拆分为 UserInfo（展示）、UserForm（提交）、PermissionGuard（权限控制）等组件。
函数职责 ：一个函数只完成一个功能。例如，formatDate 只负责日期格式化，不掺杂数据请求或 DOM 操作。
模块划分 ：工具库按功能拆分（如 api/ 处理请求、utils/ 处理工具函数、hooks/ 处理逻辑复用），避免一个模块包含多种不相关功能。

反例：一个 ProductList 组件既负责渲染商品列表，又处理筛选逻辑、购物车添加，还包含数据请求------修改筛选逻辑可能影响渲染，导致维护困难。

定义：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即通过扩展新增功能，而非修改现有代码。 前端表现：

组件扩展 ：通过 props 或插槽（Slot）扩展组件功能，而非直接修改组件源码。例如，Button 组件通过 type 属性（primary/success）扩展样式，而非每次新增类型都修改组件内部。
插件化设计 ：使用插件或中间件机制扩展功能。例如，Vue 的 use 方法注册插件（如 vue-router），React 的 HOC（高阶组件）或自定义 Hooks 扩展组件能力。
配置驱动：通过配置文件定义行为，而非硬编码。例如，表单验证规则通过配置数组定义，新增规则只需添加配置项，无需修改验证逻辑。

反例：每次给 Table 组件新增一种列类型（如 image 列），都直接修改 Table 组件的渲染逻辑，导致组件越来越臃肿，且容易引入 Bug。

定义：子类/派生类必须能够替换其基类/父类，且不影响程序的正确性。即父类能出现的地方，子类都能无缝替换。 前端表现：

组件继承/复用 ：如果一个组件 SpecialButton 继承自 Button，那么在任何使用 Button 的地方，替换为 SpecialButton 都应正常工作，且不改变原有逻辑。例如，SpecialButton 不能修改 Button 的核心 props（如 onClick）的行为。
接口一致性 ：自定义 Hooks 或工具函数的返回值应保持一致性。例如，useRequest 和 useCachedRequest 都返回 { data, loading, error }，调用方无需区分具体使用哪个 Hook。

反例：BaseInput 组件支持 onChange 回调（参数为输入值），但派生的 NumberInput 却将 onChange 参数改为 { value, isValid }，导致替换后调用方报错。

定义：不应强迫客户端依赖它不需要的接口。即接口应细化，避免过大的"万能接口"。 前端表现：

Props 拆分 ：组件 props 应最小化，只暴露必要的属性。例如，UserAvatar 组件只需 src 和 size props，无需传入整个 user 对象（避免依赖不需要的用户信息）。
按需引入 ：工具函数或组件库按功能拆分，避免引入冗余代码。例如，Lodash 支持按需导入（import { debounce } from 'lodash'），而非必须引入整个库。
Hook 职责单一 ：自定义 Hooks 应聚焦单一功能，避免返回无关数据。例如，useUser 只返回用户信息，usePermissions 只返回权限相关数据，而非合并为一个庞大的 useUserAndPermissions。

反例：一个 Form 组件的 onSubmit 回调被迫接收 { values, errors, touched, reset, setFieldValue } 等大量参数，即使调用方只需要 values。

定义：高层模块不应依赖低层模块，两者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象。 前端表现：

依赖注入 ：组件或函数通过参数接收依赖，而非内部硬编码。例如，一个处理用户数据的组件 UserProfile，通过 props 接收 userService（数据请求工具），而非在组件内部直接调用 axios.get('/user')------这样可替换为 mock 服务用于测试。
抽象接口 ：定义通用接口（如类型、协议），具体实现依赖接口。例如，定义 Storage 接口（get/set 方法），localStorage 和 sessionStorage 都实现该接口，业务代码只需依赖 Storage 接口，无需关心具体是哪种存储。
状态管理解耦 ：React 的 useContext 或 Redux 中，组件依赖的是状态抽象（如 useSelector），而非具体的状态实现（如状态存在哪个 reducer 中）。

反例：组件 OrderList 内部直接调用 fetchOrders() 函数获取数据，若后续需要改用 GraphQL 或 mock 数据，必须修改 OrderList 源码。

SOLID 原则的核心是拆分与解耦，在前端开发中：