在 JavaScript 和 TypeScript 框架中应用 SOLID 原则
简介
solid 原则构成了干净、可扩展和可维护的软件开发的基础。尽管这些原则起源于面向对象编程 (oop)，但它们可以有效地应用于 javascript (js) 和 typescript (ts) 框架，例如 react 和 angular。本文通过 js 和 ts 中的实际示例解释了每个原理。
1.单一职责原则 (srp)
原则：一个类或模块应该只有一个改变的理由。它应该负责单一功能。
- javascript 示例（react）：
在 react 中，我们经常看到组件负责太多事情——例如管理 ui 和业务逻辑。
反模式：
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 组件违反了 srp，因为它同时处理 ui 渲染和数据获取。
重构：
// custom hook for fetching user data
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 component
function userprofile({ userid }) {
const user = useuserdata(userid); // moved data fetching logic to a hook
return <div>{user?.name}</div>;
}
通过使用自定义钩子 (useuserdata)，我们将数据获取逻辑与ui分离，让每个部分负责单个任务。
- typescript 示例（angular）：
在 angular 中，服务和组件可能因多重职责而变得混乱。
反模式：
@injectable()
export class userservice {
constructor(private http: httpclient) {}
getuser(userid: string) {
return this.http.get(`/api/users/${userid}`);
}
updateuserprofile(userid: string, data: any) {
// updating the profile and handling notifications
return this.http.put(`/api/users/${userid}`, data).subscribe(() => {
console.log('user updated');
alert('profile updated successfully');
});
}
}
此userservice 具有多种职责：获取、更新和处理通知。
重构：
@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);
}
}
// separate notification service
@injectable()
export class notificationservice {
notify(message: string) {
alert(message);
}
}
通过将通知处理拆分为单独的服务 (notificationservice)，我们确保每个类都有单一职责。
2.开闭原则 (ocp)
原则：软件实体应该对扩展开放，对修改关闭。这意味着您应该能够扩展模块的行为而不更改其源代码。
- javascript 示例（react）：
您可能有一个运行良好的表单验证功能，但将来可能需要额外的验证逻辑。
反模式：
function validate(input) {
if (input.length
<p>每当您需要新的验证规则时，您都必须修改此函数，这违反了 ocp。</p>
<p><strong>重构：</strong><br></p>
function validate(input, rules) {
return rules.map(rule => rule(input)).find(result => result !== 'valid') || 'valid input';
}
const lengthrule = input => input.length >= 5 ? 'valid' : 'input is too short';
const emailrule = input => input.includes('@') ? 'valid' : 'invalid email';
validate('test@domain.com', [lengthrule, emailrule]);
现在，我们可以在不修改原始验证函数的情况下扩展验证规则，遵守 ocp。
- typescript 示例（angular）：
在 angular 中，服务和组件的设计应允许在不修改核心逻辑的情况下添加新功能。
反模式：
export class notificationservice {
send(type: 'email' | 'sms', message: string) {
if (type === 'email') {
// send email
} else if (type === 'sms') {
// send sms
}
}
}
此服务违反了 ocp，因为每次添加新的通知类型（例如推送通知）时都需要修改发送方法。
重构：
interface notification {
send(message: string): void;
}
@injectable()
export class emailnotification implements notification {
send(message: string) {
// send email logic
}
}
@injectable()
export class smsnotification implements notification {
send(message: string) {
// send sms logic
}
}
@injectable()
export class notificationservice {
constructor(private notifications: notification[]) {}
notify(message: string) {
this.notifications.foreach(n => n.send(message));
}
}
现在，添加新的通知类型只需要创建新的类，而无需更改notificationservice本身。
3.里氏替换原理 (lsp)
原则：子类型必须可以替换其基本类型。派生类或组件应该能够替换基类而不影响程序的正确性。
- javascript 示例（react）：
当使用高阶组件 (hoc) 或有条件地渲染不同组件时，lsp 有助于确保所有组件的行为可预测。
反模式：
function button({ onclick }) {
return <button onclick="{onclick}">click me</button>;
}
function linkbutton({ href }) {
return <a href="%7Bhref%7D">click me</a>;
}
<button onclick="{()"> {}} />;
<linkbutton href="/home"></linkbutton>;
</button>
这里，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="%7Bhref%7D">click me</a>
</clickable>;
}
现在，button 和 linkbutton 的行为类似，都遵循 lsp。
- typescript 示例（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;
}
}
现在，可以在不违反 lsp 的情况下替换 square 和 rectangle。
4.接口隔离原则（isp）：
原则：客户端不应该被迫依赖他们不使用的接口。
- javascript 示例（react）：
react 组件有时会收到不必要的 props，导致紧密耦合和庞大的代码。
反模式：
function multipurposecomponent({ user, posts, comments }) {
return (
<div>
<userprofile user="{user}"></userprofile><userposts posts="{posts}"></userposts><usercomments comments="{comments}"></usercomments>
</div>
);
}
这里，组件依赖于多个 props，即使它可能并不总是使用它们。
重构：
function userprofilecomponent({ user }) {
return <userprofile user="{user}"></userprofile>;
}
function userpostscomponent({ posts }) {
return <userposts posts="{posts}"></userposts>;
}
function usercommentscomponent({ comments }) {
return <usercomments comments="{comments}"></usercomments>;
}
通过将组件拆分为更小的组件，每个组件仅取决于它实际使用的数据。
- typescript 示例（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 接口，我们确保客户只依赖他们需要的东西。
5.依赖倒置原则（dip）：
原则：高层模块不应该依赖于低层模块。两者都应该依赖于抽象（例如接口）。
- javascript 示例（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}"></usercomponent>;
通过将 fetchuserdata 注入到组件中，我们可以轻松地更换测试或不同用例的实现。
- typescript 示例（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));
}
}
</user></user>
通过依赖接口（userservice），usercomponent 现在与 apiuserservice 的具体实现解耦。
后续步骤
无论您是使用 react 或 angular 等框架开发前端，还是使用 node.js 开发后端，solid 原则都可以作为指导，确保您的软件架构保持可靠。
要将这些原则完全融入您的项目中：
- 定期练习：重构现有代码库以应用 solid 原则并审查代码是否遵守。
- 与您的团队合作：通过代码审查和围绕干净架构的讨论来鼓励最佳实践。
- 保持好奇心：坚实的原则仅仅是开始。探索基于这些基础知识的其他架构模式，例如 mvc、mvvm 或 cqrs，以进一步改进您的设计。
结论
solid 原则对于确保代码干净、可维护和可扩展非常有效，即使在 react 和 angular 等 javascript 和 typescript 框架中也是如此。应用这些原则使开发人员能够编写灵活且可重用的代码，这些代码易于随着需求的发展而扩展和重构。通过遵循 solid，您可以使您的代码库变得强大并为未来的增长做好准备。
以上就是在 JavaScript 和 TypeScript 框架中应用 SOLID 原则的详细内容，更多请关注其它相关文章！