Dans ce blog, je vais démontrer la mise en œuvre des principes SOLID dans une application React. À la fin de cet article, vous maîtriserez pleinement les principes SOLID. Avant de commencer, permettez-moi de vous donner une brève introduction à ces principes.  Que sont les principes SOLID ?  Les principes SOLID sont cinq principes de conception qui nous aident à garder notre application réutilisable, maintenable, évolutive et faiblement couplée. Les principes SOLID sont :   Principe de responsabilité unique   Principe Ouvert-Fermé   Principe de substitution de Liskov   Principe de ségrégation des interfaces   Principe d'inversion de dépendance  Bon, examinons chacun de ces principes individuellement. J'utilise React comme exemple, mais les concepts de base sont similaires à d'autres langages de programmation et frameworks.   Principe de responsabilité unique   "Un module doit être responsable devant un, et un seul, acteur." - Wikipédia.  Le principe de responsabilité unique stipule qu'un composant doit avoir un objectif ou une responsabilité clairs. Il doit se concentrer sur une fonctionnalité ou un comportement spécifique et éviter d'entreprendre des tâches sans rapport. Suivre SRP rend les composants plus ciblés, modulaires et faciles à comprendre et à modifier. Voyons la mise en œuvre réelle.   // ❌ Bad Practice: Component with Multiple Responsibilities const Products = () => { return ( <div className="products"> {products.map((product) => ( <div key={product?.id} className="product"> <h3>{product?.name}</h3> <p>${product?.price}</p> </div> ))} </div> ); };  Dans l'exemple ci-dessus, le composant   enfreint le principe de responsabilité unique en assumant plusieurs responsabilités. Il gère l'itération des produits et gère le rendu de l'interface utilisateur pour chaque produit. Cela peut rendre le composant difficile à comprendre, à maintenir et à tester à l'avenir. Products  Au lieu de cela, faites ceci pour adhérer au SRP :   // ✅ Good Practice: Separating Responsibilities into Smaller Components import Product from './Product'; import products from '../../data/products.json'; const Products = () => { return ( <div className="products"> {products.map((product) => ( <Product key={product?.id} product={product} /> ))} </div> ); }; // Product.js // Separate component responsible for rendering the product details const Product = ({ product }) => { return ( <div className="product"> <h3>{product?.name}</h3> <p>${product?.price}</p> </div> ); };  Cette séparation garantit que chaque composant a une responsabilité unique, ce qui les rend plus faciles à comprendre, à tester et à entretenir.   Principe Ouvert-Fermé   "Les entités logicielles (classes, modules, fonctions, etc.) doivent être ouvertes pour extension, mais fermées pour modification." - Wikipédia.  Le principe ouvert-fermé souligne que les composants doivent être ouverts pour l'extension (peut ajouter de nouveaux comportements ou fonctionnalités) mais fermés pour modification (le code existant doit rester inchangé). Ce principe encourage la création de code résilient au changement, modulaire et facilement maintenable. Voyons la mise en œuvre réelle.   // ❌ Bad Practice: Violating the Open-Closed Principle // Button.js // Existing Button component const Button = ({ text, onClick }) => { return ( <button onClick={onClick}> {text} </button> ); } // Button.js // Modified Existing Button component with additional icon prop (modification) const Button = ({ text, onClick, icon }) => { return ( <button onClick={onClick}> <i className={icon} /> <span>{text}</span> </button> ); } // Home.js // 👇 Avoid: Modified existing component prop const Home = () => { const handleClick= () => {}; return ( <div> {/* ❌ Avoid this */} <Button text="Submit" onClick={handleClick} icon="fas fa-arrow-right" /> </div> ); }  Dans l'exemple ci-dessus, nous modifions le composant   existant en ajoutant un accessoire   . La modification d'un composant existant pour répondre à de nouvelles exigences enfreint le principe ouvert-fermé. Ces changements fragilisent le composant et introduisent le risque d'effets secondaires involontaires lorsqu'il est utilisé dans différents contextes. Button icon  Au lieu de cela, faites ceci :   // ✅ Good Practice: Open-Closed Principle // Button.js // Existing Button functional component const Button = ({ text, onClick }) => { return ( <button onClick={onClick}> {text} </button> ); } // IconButton.js // IconButton component // ✅ Good: You have not modified anything here. const IconButton = ({ text, icon, onClick }) => { return ( <button onClick={onClick}> <i className={icon} /> <span>{text}</span> </button> ); } const Home = () => { const handleClick = () => { // Handle button click event } return ( <div> <Button text="Submit" onClick={handleClick} /> {/* <IconButton text="Submit" icon="fas fa-heart" onClick={handleClick} /> </div> ); }  Dans l'exemple ci-dessus, nous créons un composant fonctionnel   séparé. Le composant   encapsule le rendu d'un bouton d'icône sans modifier le composant   existant. Il adhère au principe ouvert-fermé en étendant la fonctionnalité par la composition plutôt que par la modification. IconButton IconButton Button   Principe de substitution de Liskov   "Les objets de sous-type doivent être substituables aux objets de supertype" - Wikipedia.  Le principe de substitution de Liskov (LSP) est un principe fondamental de la programmation orientée objet qui met l'accent sur la nécessité de substituabilité des objets au sein d'une hiérarchie. Dans le contexte des composants React, LSP promeut l'idée que les composants dérivés devraient pouvoir remplacer leurs composants de base sans affecter l'exactitude ou le comportement de l'application. Voyons la mise en œuvre réelle.   // ⚠️ Bad Practice // This approach violates the Liskov Substitution Principle as it modifies // the behavior of the derived component, potentially resulting in unforeseen // problems when substituting it for the base Select component. const BadCustomSelect = ({ value, iconClassName, handleChange }) => { return ( <div> <i className={iconClassName}></i> <select value={value} onChange={handleChange}> <options value={1}>One</options> <options value={2}>Two</options> <options value={3}>Three</options> </select> </div> ); }; const LiskovSubstitutionPrinciple = () => { const [value, setValue] = useState(1); const handleChange = (event) => { setValue(event.target.value); }; return ( <div> {/** ❌ Avoid this */} {/** Below Custom Select doesn't have the characteristics of base `select` element */} <BadCustomSelect value={value} handleChange={handleChange} /> </div> );  Dans l'exemple ci-dessus, nous avons un composant   destiné à servir d'entrée de sélection personnalisée dans React. Cependant, il viole le principe de substitution de Liskov (LSP) car il limite le comportement de l'élément   de base. BadCustomSelect select  Au lieu de cela, faites ceci :   // ✅ Good Practice // This component follows the Liskov Substitution Principle and allows the use of select's characteristics. const CustomSelect = ({ value, iconClassName, handleChange, ...props }) => { return ( <div> <i className={iconClassName}></i> <select value={value} onChange={handleChange} {...props}> <options value={1}>One</options> <options value={2}>Two</options> <options value={3}>Three</options> </select> </div> ); }; const LiskovSubstitutionPrinciple = () => { const [value, setValue] = useState(1); const handleChange = (event) => { setValue(event.target.value); }; return ( <div> {/* ✅ This CustomSelect component follows the Liskov Substitution Principle */} <CustomSelect value={value} handleChange={handleChange} defaultValue={1} /> </div> ); };  Dans le code révisé, nous avons un composant   destiné à étendre les fonctionnalités de l'élément   standard dans React. Le composant accepte des accessoires tels que   ,   ,   et des accessoires supplémentaires à l'aide de l'opérateur de propagation   . En permettant l'utilisation des caractéristiques de l'élément   et en acceptant des accessoires supplémentaires, le composant   suit le principe de substitution de Liskov (LSP). CustomSelect select value iconClassName handleChange ...props select CustomSelect   Principe de séparation des interfaces   "Aucun code ne devrait être contraint de dépendre de méthodes qu'il n'utilise pas." - Wikipédia.  Le principe de ségrégation des interfaces (ISP) suggère que les interfaces doivent être ciblées et adaptées aux besoins spécifiques des clients plutôt que d'être trop larges et d'obliger les clients à mettre en œuvre des fonctionnalités inutiles. Voyons la mise en œuvre réelle.   // ❌ Avoid: disclose unnecessary information for this component // This introduces unnecessary dependencies and complexity for the component const ProductThumbnailURL = ({ product }) => { return ( <div> <img src={product.imageURL} alt={product.name} /> </div> ); }; // ❌ Bad Practice const Products = ({ product }) => { return ( <div> <ProductThumbnailURL product={product} /> <h4>{product?.name}</h4> <p>{product?.description}</p> <p>{product?.price}</p> </div> ); }; const Products = () => { return ( <div> {products.map((product) => ( <Product key={product.id} product={product} /> ))} </div> ); }  Dans l'exemple ci-dessus, nous transmettons tous les détails du produit au composant   , même s'il ne l'exige pas. Cela ajoute des risques et une complexité inutiles au composant et enfreint le principe de séparation des interfaces (ISP). ProductThumbnailURL  Refactorisons pour adhérer au FAI :   // ✅ Good: reducing unnecessary dependencies and making // the codebase more maintainable and scalable. const ProductThumbnailURL = ({ imageURL, alt }) => { return ( <div> <img src={imageURL} alt={alt} /> </div> ); }; // ✅ Good Practice const Products = ({ product }) => { return ( <div> <ProductThumbnailURL imageURL={product.imageURL} alt={product.name} /> <h4>{product?.name}</h4> <p>{product?.description}</p> <p>{product?.price}</p> </div> ); }; const Products = () => { return ( <div> {products.map((product) => ( <Product key={product.id} product={product} /> ))} </div> ); };  Dans le code révisé, le composant   ne reçoit que les informations requises au lieu de tous les détails du produit. Il prévient les risques inutiles et favorise le principe de ségrégation des interfaces (ISP). ProductThumbnailURL   Principe d'inversion de dépendance   "Une entité devrait dépendre d'abstractions, pas de concrétions" - Wikipedia.  Le principe d'inversion de dépendance (DIP) souligne que les composants de haut niveau ne doivent pas dépendre des composants de bas niveau. Ce principe favorise le couplage lâche et la modularité et facilite la maintenance des systèmes logiciels. Voyons la mise en œuvre réelle.   // ❌ Bad Practice // This component follows concretion instead of abstraction and // breaks Dependency Inversion Principle const CustomForm = ({ children }) => { const handleSubmit = () => { // submit operations }; return <form onSubmit={handleSubmit}>{children}</form>; }; const DependencyInversionPrinciple = () => { const [email, setEmail] = useState(); const handleChange = (event) => { setEmail(event.target.value); }; const handleFormSubmit = (event) => { // submit business logic here }; return ( <div> {/** ❌ Avoid: tightly coupled and hard to change */} <BadCustomForm> <input type="email" value={email} onChange={handleChange} name="email" /> </BadCustomForm> </div> ); };  Le composant   est étroitement couplé à ses enfants, ce qui empêche la flexibilité et rend difficile la modification ou l'extension de son comportement. CustomForm  Au lieu de cela, faites ceci :   // ✅ Good Practice // This component follows abstraction and promotes Dependency Inversion Principle const AbstractForm = ({ children, onSubmit }) => { const handleSubmit = (event) => { event.preventDefault(); onSubmit(); }; return <form onSubmit={handleSubmit}>{children}</form>; }; const DependencyInversionPrinciple = () => { const [email, setEmail] = useState(); const handleChange = (event) => { setEmail(event.target.value); }; const handleFormSubmit = () => { // submit business logic here }; return ( <div> {/** ✅ Use the abstraction instead */} <AbstractForm onSubmit={handleFormSubmit}> <input type="email" value={email} onChange={handleChange} name="email" /> <button type="submit">Submit</button> </AbstractForm> </div> ); };  Dans le code révisé, nous introduisons le composant   , qui agit comme une abstraction pour le formulaire. Il reçoit la fonction   en tant que prop et gère la soumission du formulaire. Cette approche nous permet d'échanger ou d'étendre facilement le comportement du formulaire sans modifier le composant de niveau supérieur. AbstractForm onSubmit   Conclusion  Les principes SOLID fournissent des lignes directrices qui permettent aux développeurs de créer des solutions logicielles bien conçues, maintenables et extensibles. En adhérant à ces principes, les développeurs peuvent atteindre la modularité, la réutilisabilité du code, la flexibilité et la complexité réduite du code.  J'espère que ce blog vous a fourni des informations précieuses et vous a inspiré à appliquer ces principes dans vos projets React existants ou à venir.   Reste curieux; continuez à coder !  Référence:   https://codesandbox.io/s/solid-principles-react-o4hn5s   Également publié   . ici

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Make resilience your competitive advantage

Maîtriser des principes SOLIDES comme le dos de votre main en seulement 8 minutes !

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Boostez votre productivité avec ces 18 outils de développement 🚀🔥

Guide de l'architecte pour créer une architecture de référence pour un datalake IA/ML

Créer des produits cryptographiques centrés sur l'utilisateur : l'importance des retours clients

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps