Le principe de substitution de Liskov en pratique | C#

Le principe de substitution de Liskov en pratique | C#

Introduction

Dans cet article, nous allons discuter du principe de substitution de Liskov en C # avec un exemple. Veuillez lire notre article précédent avant de passer à cet article où nous avons discuté du principe ouvert-fermé en C # avec un exemple. La lettre L en SOLID signifie le mot “Liskov“, représente le principe de substitution de Liskov. 

Qu’est-ce que le principe de substitution de Liskov?

Le principe de substitution de Liskov, nommé et défini à l’origine par Barbara Liskov, stipule que nous devrions être en mesure de traiter une classe enfant comme si elle était la classe parente et cela signifie essentiellement que toutes les classes dérivées doivent conserver les fonctionnalités de leur classe parente et ne peuvent remplacer aucune fonctionnalité fournie par le parent.

Comment pouvons-nous atteindre le principe ouvert-fermé C#  ?

Supposons que nous ayons 3 bases de données (clients hypothécaires, clients de comptes courants et clients de comptes d’épargne) qui fournissent des données client et que nous ayons besoin des détails du client pour le nom de famille du client donné. Maintenant, nous pouvons obtenir plus d’un détail client de ces 3 bases de données contre le nom de famille donné.

Exemple d’implémentation

La couche de modèle d’affaires

public class Customer { // customer detail properties... }
Code language: PHP (php)

La couche d’accès aux données :

public interface IDataAccess { Customer GetDetails(string lastName); }
Code language: PHP (php)

Ci-dessous, l’interface est implémentée par la classe abstraite, cette classe abstraite a une méthode commune « GetDetails » pour les 3 bases de données qui est étendue par chacune des classes de base de données comme indiqué dans le bout de code suivant.

public abstract class BaseDataAccess : IDataAccess { /// <summary> Enterprise library data block Database object. </summary> public Database Database; public Customer GetDetails(string lastName) { // use the database object to call the stored procedure to retirve the customer detials } }
Code language: HTML, XML (xml)

Accès aux données du client hypothécaire :

public class MortgageCustomerDataAccess : BaseDataAccess { public MortgageCustomerDataAccess(IDatabaseFactory factory) { this.Database = factory.GetMortgageCustomerDatabase(); } }

Ci-dessous l’accès aux données client du compte actuel :

public class CurrentAccountCustomerDataAccess : BaseDataAccess { public CurrentAccountCustomerDataAccess(IDatabaseFactory factory) { this.Database = factory.GetCurrentAccountCustomerDatabase(); } }

Ci-dessous l’accès aux données client du compte d’épargne :

public class SavingsAccountCustomerDataAccess : BaseDataAccess { public SavingsAccountCustomerDataAccess(IDatabaseFactory factory) { this.Database = factory.GetSavingsAccountCustomerDatabase(); } }

Une fois ces 3 classes d’accès aux données définies, nous attirons maintenant notre attention sur le client. Dans la couche Business, nous avons la classe CustomerServiceManager qui renvoie les détails du client à ses clients.

Ci-dessous la couche d’affaires :

public class CustomerServiceManager : ICustomerServiceManager, BaseServiceManager { public IEnumerable<Customer> GetCustomerDetails(string lastName) { IEnumerable<IDataAccess> dataAccess = new List<IDataAccess>() { new MortgageCustomerDataAccess(new DatabaseFactory()), new CurrentAccountCustomerDataAccess(new DatabaseFactory()), new SavingsAccountCustomerDataAccess(new DatabaseFactory()) }; IList<Customer> customers = new List<Customer>(); foreach (IDataAccess nextDataAccess in dataAccess) { Customer customerDetail = nextDataAccess.GetDetails(lastName); customers.Add(customerDetail); } return customers; } }
Code language: HTML, XML (xml)

Maintenant, si nous avons une nouvelle base de données de détails client, nous pouvons simplement ajouter une nouvelle classe qui étend BaseDataAccess et fournit son objet de base de données.

Enfin, le client de la classe CustomerServiceManager appellera uniquement la méthode GetCustomerDetails, transmettra lastName et ne devrait pas se soucier de la provenance des données.

Conclusion

Ce principe est très utile pour maintenir la fonctionnalité sur les hiérarchies, et dans ce but, il convient particulièrement bien.

J’espère que cet article vous aide à comprendre le principe de substitution de Liskov un peu plus en détails. Vos commentaires et critiques constructives sont toujours appréciés.

Partagez !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *