介紹

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 中，服務和元件可能因多重職責而變得混亂。

反模式：

@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 < 5) {
    return 'Input is too short';
  }
  if (!input.includes('@')) {
    return 'Invalid email';
  }
  return 'Valid input';
}

每當您需要新的驗證規則時，您都必須修改此函數，這違反了 OCP。

重構：

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('[email protected]', [lengthRule, emailRule]);

現在，我們可以在不修改原始驗證函數的情況下擴展驗證規則，從而遵守 OCP。

• TypeScript 中的範例（角度）：

在 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={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。

• TypeScript 中的範例（角度）：

反模式：

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} />
      <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} />;
}

透過將元件拆分為更小的元件，每個元件僅取決於它實際使用的資料。

• TypeScript 中的範例（角度）：

反模式：

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} />;

透過將 fetchUserData 注入到元件中，我們可以輕鬆地更換測試或不同用例的實作。

• TypeScript 中的範例（角度）：

反模式：

@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 原則並審查程式碼是否遵守。

• 與您的團隊協作：透過程式碼審查和圍繞乾淨架構的討論來鼓勵最佳實踐。

• 保持好奇心：堅實的原則只是開始。探索基於這些基礎知識的其他架構模式，例如 MVC、MVVM 或 CQRS，以進一步改進您的設計。

結論

SOLID 原則對於確保程式碼乾淨、可維護和可擴充非常有效，即使在 React 和 Angular 等 JavaScript 和 TypeScript 框架中也是如此。應用這些原則使開發人員能夠編寫靈活且可重複使用的程式碼，這些程式碼易於隨著需求的發展而擴展和重構。透過遵循 SOLID，您可以使您的程式碼庫變得強大並為未來的成長做好準備。

原文出處：https://dev.to/wafa_bergaoui/applying-solid-principles-in-javascript-and-typescript-framework-2d1d