SOLID 是一套原則。它們主要是關心代碼質量和可維護性的軟件專業人員的指導方針。

React 不是面向對象，但這些原則背后的主要思想可能是有幫助的。在本文中，我將嘗試演示如何應用這些原則來編寫更好的代碼。

在前一篇文章中，我們討論了單一責任原則。今天，我們將討論 SOLID 的第二個原則: 開閉原則。

本系列其他文章

如何應用 SOLID 原則在 React 中整理代碼之單一原則

什么是開閉原則？

Robert c. Martin 認為這個原則是面向對象設計最重要的原則。但他不是第一個定義這個概念的人。Bertrand Meyer 于 1988 年在他的《面向對象軟件構造》一書中寫到了這一點。他解釋了開放/封閉原則:

軟件實體(類、模塊、功能等)應該對擴展開放，但對修改關閉。

這個原則告訴您以這樣一種方式來編寫代碼，即您能夠在不更改現有代碼的情況下添加其他功能。

讓我們看看我們在哪里可以應用這個原則。

讓我們從一個例子開始

假設我們有一個 User 組件，其中我們傳遞用戶的詳細信息，這個類的主要目的是顯示該特定用戶的詳細信息。

這是一個很簡單的開始。但是我們的生活并不是那么簡單。幾天后，我們的經理告訴我們系統中有三種類型的用戶: SuperAdmin、 Admin 等等。

它們每個都有不同的信息和功能。

一個糟糕的解決方案

第一個也是顯而易見的解決方案：在組件中包含一個條件，并根據不同的用戶類型呈現不同的信息。

import React from 'react';
export const User = ({user}) => {
    return <>
        <div> Name: {user.name}</div>
        <div> Email: {user.email}</div>
        {
            user.type === 'SUPER_ADMIN' &&
            <div> Details about super admin</div>
        }
        {
            user.type === 'ADMIN' &&
            <div> Details about admin</div>
        }
    </>
}

你知道這里出了什么問題嗎？

首先，我們的代碼現在是凌亂的。

其次，如果我們需要其他類型的用戶怎么辦？

然后，我們需要進入 User.js，為特定類型的用戶添加另一個條件。

這明顯違反了開閉原則，因為我們不允許更改 User 組件內部的代碼。

解決方案是什么？

在這個場景中我們可以應用兩種主要的技術:

• 高階組件(HOC)
• 組件組合(Component composition)

在可能的情況下，最好采用第二種方法，但是在某些情況下，有必要使用 HOC。

現在，我們將使用 Facebook 推薦的一種技術，稱為組件組合。

讓我們創建單獨的用戶組件

現在，我們需要以這樣一種方式設計代碼，即不需要在 User.js 組件中添加條件。讓我們為 SuperAdmin 創建一個單獨的組件:

import React from 'react';
import {User} from "./User";
 
export const SuperAdmin = ({user}) => {
 
    return <>
        <User user={user} />
        <div> This is super admin user details</div>
    </>
}

類似地，另一個是針對 Admin 用戶的:

import React from 'react';
import {User} from "./User";
export const Admin = ({user}) => {
    return <>
        <User user={user} />
        <div> This is admin user details</div>
    </>
}

現在我們的 App.js 文件變成了:

import React from 'react';
import Admin from './Admin'
import SuperAdmin from './SuperAdmin'
export default function App = () =>{
  const user = {}
  const userByTypes = {
    'admin' : <Admin /> ,
    'superadmin' : <SuperAdmin />
  }
  return <div>
    {userByTypes[`${user.type}`]}
  <div/>
}

現在我們可以根據需要創建盡可能多的用戶類型。我們針對特定用戶的邏輯是封裝的，因此我們不需要為了任何額外的修改而重新檢查代碼。

有些人可能會說，我們正在不必要地增加文件數量。當然，您可以暫時保持原樣，但是隨著應用程序的復雜性增加，您肯定會感到痛苦。

注意

SOLID 是一套原則。它們并不是強制性的，您必須應用于每個場景。作為一個經驗豐富的開發人員，您應該在代碼長度和可讀性之間找到一個很好的平衡。

要過分執著于這些原則。事實上，有一句名言可以解釋這些情況:

Too Much SOLID

所以知道這些原則是好的，但是你必須保持平衡。對于一個或兩個額外的字段，您可能不需要這些組合，但是將它們分開肯定會有長遠的幫助。

總結

了解這些原則會讓你走很長的路，因為在一天結束的時候，一段好的代碼才是最重要的，而且沒有單一的方法來做事情。