在 JavaScript 和 TypeScript 框架中应用 SOLID 原则

在 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 原则的详细内容，更多请关注www.sxiaw.com其它相关文章！