Le principe de séparation des interfaces en pratique | C#

Le principe de séparation des interfaces en pratique | C#

Introduction

Dans cet article, nous allons discuter du principe de séparation des interfaces en C#. Veuillez lire notre article précédent avant de passer à cet article où nous avons discuté du principe de substitution de Liskov en C#. La lettre I dans le principe de conception SOLID signifie en anglais “Interface“, représente le principe de séparation des interfaces.

Qu’est-ce que le principe de séparation des interfaces ?

Le principe stipule qu’aucun objet de code client ne doit être forcé de dépendre des méthodes qu’il n’utilise pas. Fondamentalement, chaque objet de code ne doit implémenter que ce dont il a besoin et ne doit pas être obligé d’implémenter autre chose.

Comment pouvons-nous atteindre ce principe ?

Si vous implémentez une interface en C# et devez lancer des exceptions NotImplementedExceptions et donc vous faites probablement quelque chose de mal.

Bien que ce qui précède, ce que vous verrez généralement ce principe décrit comme étant créé plusieurs interfaces plus petites au lieu d’une seule grande interface. C’est toujours correct, mais c’est plus un moyen de réaliser la séparation des interfaces plutôt que le principe lui-même.

Exemple d’implémentation

Nous donnons ci-dessous un exemple de violation du principe, puis factorisons cette violation.

public interface IMessage{ IList<string> ToAddress {get; set;} IList<string> BccAddresses {get; set;} string MessageBody {get; set;} string Subject {get; set;} bool Send(); } public class SmtpMessage : IMessage{ public IList<string> ToAddress {get; set;} public IList<string> BccAddresses {get; set;} public string MessageBody {get; set;} public string Subject {get; set;} public bool Send(){ // Code for sending E-mail. } } public class SmsMessage : IMessage{ public IList<string> ToAddress {get; set;} public IList<string> BccAddresses { get { throw new NonImplementedException(); } set { throw new NonImplementedException(); } } public string MessageBody {get; set;} public string Subject { get { throw new NonImplementedException(); } set { throw new NonImplementedException(); } } public bool Send(){ // Code for sending SMS. } }
Code language: HTML, XML (xml)

Dans la classe SmsMessage, nous n’avons pas besoin de BccAddresses et Subject, mais nous avons forcé de l’implémenter à cause de l’interface IMessage. C’est donc une violation du principe de séparation des interfaces.

public interface IMessage{ bool Send(IList<string> toAddress, string messageBody); } public interface IEmailMessage : IMessage{ string Subject {get; set;} IList<string> BccAddresses {get; set;} } public class SmtpMessage : IEmailMessage{ public IList<string> BccAddresses {get; set;} public string Subject {get; set;} public bool Send (IList<string> toAddress, string messageBody){ // Code for sending E-mail. } } public class SmsMessage : IMessage{ public bool Send (IList<string> toAddress, string messageBody){ // Code for sending SMS. } }
Code language: HTML, XML (xml)

Le code ci-dessus, la suppression de la violation selon le principe de séparation des interfaces.

SmsMessage n’a besoin que de Address et messageBody, nous pouvons donc maintenant utiliser l’interface IMessage pour éviter les implémentations inutiles.

Conclusion

Le principe consiste à réduire les objets de code à leur plus petite implémentation possible et à supprimer les dépendances dont l’objet n’a pas besoin pour fonctionner correctement. 

Le résultat de la mise en œuvre de ce principe, d’une manière générale, est d’avoir un grand nombre de petites interfaces ciblées qui définissent uniquement ce qui est nécessaire à leur implémentation.

Dans le prochain article, je vais discuter du principe d’inversion de dépendance en C#. J’espère que vous avez compris la nécessité et l’utilisation du  principe de séparation d’interface.

Partagez !

Laisser un commentaire

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