如何應(yīng)用?SOLID?原則在?React?中整理代碼之開閉原則

SOLID 是一套原則。它們主要是關(guān)心代碼質(zhì)量和可維護(hù)性的軟件專業(yè)人員的指導(dǎo)方針。
React 不是面向?qū)ο螅@些原則背后的主要思想可能是有幫助的。在本文中,我將嘗試演示如何應(yīng)用這些原則來編寫更好的代碼。
在前一篇文章中,我們討論了單一責(zé)任原則。今天,我們將討論 SOLID 的第二個(gè)原則: 開閉原則。
本系列其他文章
如何應(yīng)用 SOLID 原則在 React 中整理代碼之單一原則
什么是開閉原則?
Robert c. Martin 認(rèn)為這個(gè)原則是面向?qū)ο笤O(shè)計(jì)最重要的原則。但他不是第一個(gè)定義這個(gè)概念的人。Bertrand Meyer 于 1988 年在他的《面向?qū)ο筌浖?gòu)造》一書中寫到了這一點(diǎn)。他解釋了開放/封閉原則:
軟件實(shí)體(類、模塊、功能等)應(yīng)該對擴(kuò)展開放,但對修改關(guān)閉。
這個(gè)原則告訴您以這樣一種方式來編寫代碼,即您能夠在不更改現(xiàn)有代碼的情況下添加其他功能。
讓我們看看我們在哪里可以應(yīng)用這個(gè)原則。
讓我們從一個(gè)例子開始
假設(shè)我們有一個(gè) User 組件,其中我們傳遞用戶的詳細(xì)信息,這個(gè)類的主要目的是顯示該特定用戶的詳細(xì)信息。
這是一個(gè)很簡單的開始。但是我們的生活并不是那么簡單。幾天后,我們的經(jīng)理告訴我們系統(tǒng)中有三種類型的用戶: SuperAdmin、 Admin 等等。
它們每個(gè)都有不同的信息和功能。
一個(gè)糟糕的解決方案
第一個(gè)也是顯而易見的解決方案:在組件中包含一個(gè)條件,并根據(jù)不同的用戶類型呈現(xiàn)不同的信息。
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>
}
</>
}你知道這里出了什么問題嗎?
首先,我們的代碼現(xiàn)在是凌亂的。
其次,如果我們需要其他類型的用戶怎么辦?
然后,我們需要進(jìn)入 User.js,為特定類型的用戶添加另一個(gè)條件。
這明顯違反了開閉原則,因?yàn)槲覀儾辉试S更改 User 組件內(nèi)部的代碼。
解決方案是什么?
在這個(gè)場景中我們可以應(yīng)用兩種主要的技術(shù):
- 高階組件(HOC)
- 組件組合(Component composition)
在可能的情況下,最好采用第二種方法,但是在某些情況下,有必要使用 HOC。
現(xiàn)在,我們將使用 Facebook 推薦的一種技術(shù),稱為組件組合。
讓我們創(chuàng)建單獨(dú)的用戶組件
現(xiàn)在,我們需要以這樣一種方式設(shè)計(jì)代碼,即不需要在 User.js 組件中添加條件。讓我們?yōu)?SuperAdmin 創(chuàng)建一個(gè)單獨(dú)的組件:
import React from 'react';
import {User} from "./User";
export const SuperAdmin = ({user}) => {
return <>
<User user={user} />
<div> This is super admin user details</div>
</>
}類似地,另一個(gè)是針對 Admin 用戶的:
import React from 'react';
import {User} from "./User";
export const Admin = ({user}) => {
return <>
<User user={user} />
<div> This is admin user details</div>
</>
}現(xiàn)在我們的 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/>
}現(xiàn)在我們可以根據(jù)需要?jiǎng)?chuàng)建盡可能多的用戶類型。我們針對特定用戶的邏輯是封裝的,因此我們不需要為了任何額外的修改而重新檢查代碼。
有些人可能會(huì)說,我們正在不必要地增加文件數(shù)量。當(dāng)然,您可以暫時(shí)保持原樣,但是隨著應(yīng)用程序的復(fù)雜性增加,您肯定會(huì)感到痛苦。
注意
SOLID 是一套原則。它們并不是強(qiáng)制性的,您必須應(yīng)用于每個(gè)場景。作為一個(gè)經(jīng)驗(yàn)豐富的開發(fā)人員,您應(yīng)該在代碼長度和可讀性之間找到一個(gè)很好的平衡。
要過分執(zhí)著于這些原則。事實(shí)上,有一句名言可以解釋這些情況:
Too Much SOLID
所以知道這些原則是好的,但是你必須保持平衡。對于一個(gè)或兩個(gè)額外的字段,您可能不需要這些組合,但是將它們分開肯定會(huì)有長遠(yuǎn)的幫助。
總結(jié)
了解這些原則會(huì)讓你走很長的路,因?yàn)樵谝惶旖Y(jié)束的時(shí)候,一段好的代碼才是最重要的,而且沒有單一的方法來做事情。
到此這篇關(guān)于如何應(yīng)用 SOLID 原則在 React 中整理代碼之開閉原則的文章就介紹到這了,更多相關(guān)React SOLID 原則 開閉原則內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Shopee在React?Native?架構(gòu)方面的探索及發(fā)展歷程
這篇文章主要介紹了Shopee在React?Native?架構(gòu)方面的探索,本文會(huì)從發(fā)展歷史、架構(gòu)模型、系統(tǒng)設(shè)計(jì)、遷移方案四個(gè)方向逐一介紹我們?nèi)绾我徊讲降貪M足多團(tuán)隊(duì)在復(fù)雜業(yè)務(wù)中的開發(fā)需求,需要的朋友可以參考下2022-07-07
ForwardRef?useImperativeHandle方法demo
這篇文章主要為大家介紹了ForwardRef?useImperativeHandle方法demo,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-03-03
使用React+SpringBoot開發(fā)一個(gè)協(xié)同編輯的表格文檔實(shí)現(xiàn)步驟
隨著云計(jì)算和團(tuán)隊(duì)協(xié)作的興起,協(xié)同編輯成為了許多企業(yè)和組織中必不可少的需求,本文小編就將為大家介紹如何使用React+SpringBoot簡單的開發(fā)一個(gè)協(xié)同編輯的表格文檔,感興趣的朋友一起看看吧2023-11-11
ReactNative支付密碼輸入框?qū)崿F(xiàn)詳解
這篇文章主要為大家介紹了ReactNative支付密碼輸入框?qū)崿F(xiàn)詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11

