如何应用 SOLID 原则在 React 中整理代码之开闭原则

目录
  • 本系列其他文章
  • 什么是开闭原则?
  • 让我们从一个例子开始
  • 一个糟糕的解决方案
  • 解决方案是什么?
  • 让我们创建单独的用户组件
  • 注意
  • 总结

SOLID 是一套原则。它们主要是关心代码质量和可维护性的软件专业人员的指导方针。

React 不是面向对象,但这些原则背后的主要思想可能是有帮助的。在本文中,我将尝试演示如何应用这些原则来编写更好的代码。

在前一篇文章中,我们讨论了单一责任原则。今天,我们将讨论 SOLID 的第二个原则: 开闭原则。

本系列其他文章

如何应用 SOLID 原则在 React 中整理代码之单一原则

什么是开闭原则?

Robert c. Martin 认为这个原则是面向对象设计最重要的原则。但他不是第一个定义这个概念的人。Bertrand Meyer 于 1988 年在他的《面向对象软件构造》一书中写到了这一点。他解释了开放/封闭原则:

软件实体(类、模块、功能等)应该对扩展开放,但对修改关闭。

这个原则告诉您以这样一种方式来编写代码,即您能够在不更改现有代码的情况下添加其他功能。

让我们看看我们在哪里可以应用这个原则。

让我们从一个例子开始

假设我们有一个 User 组件,其中我们传递用户的详细信息,这个类的主要目的是显示该特定用户的详细信息。

这是一个很简单的开始。但是我们的生活并不是那么简单。几天后,我们的经理告诉我们系统中有三种类型的用户: SuperAdminAdmin 等等。

它们每个都有不同的信息和功能。

一个糟糕的解决方案

第一个也是显而易见的解决方案:在组件中包含一个条件,并根据不同的用户类型呈现不同的信息。

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

所以知道这些原则是好的,但是你必须保持平衡。对于一个或两个额外的字段,您可能不需要这些组合,但是将它们分开肯定会有长远的帮助。

总结

了解这些原则会让你走很长的路,因为在一天结束的时候,一段好的代码才是最重要的,而且没有单一的方法来做事情。

到此这篇关于如何应用 SOLID 原则在 React 中整理代码之开闭原则的文章就介绍到这了,更多相关React SOLID 原则 开闭原则内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 在React中应用SOLID原则的方法

    目录 1.单一职责原则(SRP) 2.开放封闭原则(OCP) 3.里氏替换原则(LSP) 4.接口隔离原则(ISP) 5.依赖倒置原则(DIP) 6.小结 在面向对象编程(OOP)中,SOLID 原则是设计模式的基础,它的每个字母代表一种设计原则: 单一职责原则(SRP) 开放封闭原则(OCP) 里氏替换原则(LSP) 接口隔离原则(ISP) 依赖倒置原则(DIP) 下面就来看看每个原则的含义以及如何在 React 中应用 SOLID 原则! 1.单一职责原则(SRP) 单一职责原则的定义是每个

  • 如何应用 SOLID 原则在 React 中整理代码之开闭原则

    目录 本系列其他文章 什么是开闭原则? 让我们从一个例子开始 一个糟糕的解决方案 解决方案是什么? 让我们创建单独的用户组件 注意 总结 SOLID 是一套原则.它们主要是关心代码质量和可维护性的软件专业人员的指导方针. React 不是面向对象,但这些原则背后的主要思想可能是有帮助的.在本文中,我将尝试演示如何应用这些原则来编写更好的代码. 在前一篇文章中,我们讨论了单一责任原则.今天,我们将讨论 SOLID 的第二个原则: 开闭原则. 本系列其他文章 如何应用 SOLID 原则在 React

  • C#面向对象编程中开闭原则的示例详解

    目录 开闭原则 C# 示例 改进 总结 在面向对象编程中,SOLID 是五个设计原则的首字母缩写,旨在使软件设计更易于理解.灵活和可维护.这些原则是由美国软件工程师和讲师罗伯特·C·马丁(Robert Cecil Martin)提出的许多原则的子集,在他2000年的论文<设计原则与设计模式>中首次提出. SOLID 原则包含: S:单一功能原则(single-responsibility principle) O:开闭原则(open-closed principle) L:里氏替换原则(Lis

  • 实例讲解Java设计模式编程中的OCP开闭原则

    定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.          开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,它

  • 六大设计原则之开闭原则

    定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来: 在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案: 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统. 开闭原则可能是设计模式六项原则中定义最模糊的一个了,它只告诉我们

  • ocp开闭原则_动力节点Java学院整理

    开闭原则(Open Closed Principle)是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统. 定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. Softeware entities like classes,modules and functions should be open for extension but closed for modifications. 开闭原则的含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码

  • 解析Java编程中设计模式的开闭原则的运用

    开闭原则(Open Closed Principle)是Java世界里最基础的设计原则,它指导我们如何建立一个稳定的.灵活的系统. 定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. Softeware entities like classes,modules and functions should be open for extension but closed for modifications. 开闭原则的含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码

  • 浅谈C# 抽象类与开闭原则

    1.抽象类与抽象方法: (1)使用关键字abstract修饰的类,称为抽象类. (2)抽象类只是用到一个类所具有的行为,不能单独通过创建对象来使用.使用new是错误的.可以通过派生类来实现其函数成员的具体逻辑. (3)抽象类中可以有抽象方法,也可以没有任何抽象方法.只要类中存在一个抽象方法,这个类就是抽象类. (4)抽象类不能是静态的(static)或者密封的(sealed) 下面就是一个简单的抽象类 abstract class Vehicle { public abstract void t

  • java面向对象设计原则之开闭原则示例解析

    概念 唯一不变的是不断的变化,在软件开发中应该对需求的变化持开放态度,我们要做的就是如何将这种变化对我们现有的成果带来最小的冲击.开闭原则直接面对面向对象程序的目标扩展性和可维护性,要求对扩展开放,对修改关闭:即在不修改原有代码的情况下改变模块的行为.该原则是面向对象程序设计的总原则,也是度量程序设计的好与坏的唯一标准 实现 开闭原则的实现策略主要在面向对象的封装性和多态性的基础上,利用面向对象的其他原则完成的. 1.使用多态机制解决问题. 如:远程监控系统使用数据传输使用427版本的协议,一年

  • Java设计模式之开闭原则精解

    目录 1.什么是开闭原则? 2.违反Ocp代码案例 3.遵守Ocp代码案例 1.什么是开闭原则? 开闭原则(Open Closed Principle)是编程中最基础.最重要的设计原则. 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节. 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则. 2.违反Ocp代码案例 package c

  • Java设计模式七大原则之开闭原则详解

    目录 定义 案例 需求 方案一 执行结果 方案二 执行结果 对比分析 总结 定义 开闭原则( Open Close Principle ),又称为OCP原则,即一个软件实体如类,模块和函数应该对扩展开放,对修改关闭.其中,对扩展开放是针对提供方来说的,对修改关闭是针对调用方来说的. 案例 需求 购买东西的时候,根据支付类型的不同使用不同的方式进行支付,当类型为1时,使用微信支付:当类型为2时,使用支付宝支付 方案一 定义支付类型 /** * 支付类型 * @author:liyajie * @c

随机推荐