Lors de la lecture d'articles sur les FAI, il semble y avoir deux définitions contradictoires des FAI:
Selon la première définition (voir 1 , 2 , 3 ), le FAI déclare que les classes implémentant l'interface ne devraient pas être forcées d'implémenter des fonctionnalités dont elles n'ont pas besoin. Ainsi, la grosse interfaceIFat
interface IFat
{
void A();
void B();
void C();
void D();
}
class MyClass: IFat
{ ... }
devrait être divisé en interfaces plus petites ISmall_1etISmall_2
interface ISmall_1
{
void A();
void B();
}
interface ISmall_2
{
void C();
void D();
}
class MyClass:ISmall_2
{ ... }
puisque de cette façon mon MyClass est en mesure de mettre en œuvre que les méthodes dont il a besoin ( D()et C()), sans être obligé de fournir également des implémentations fictives pour A(), B()et C():
Mais selon la deuxième définition (voir 1 , 2 , réponse de Nazar Merza ), le FAI déclare que l' MyClientappel de méthodes sur MyServicene devrait pas être conscient des méthodes surMyService lesquelles il n'a pas besoin. En d'autres termes, si MyClientseulement besoin de la fonctionnalité de C()et D(), alors au lieu de
class MyService
{
public void A();
public void B();
public void C();
public void D();
}
/*client code*/
MyService service = ...;
service.C();
service.D();
nous devons séparer MyService's méthodes en interfaces spécifiques au client :
public interface ISmall_1
{
void A();
void B();
}
public interface ISmall_2
{
void C();
void D();
}
class MyService:ISmall_1, ISmall_2
{ ... }
/*client code*/
ISmall_2 service = ...;
service.C();
service.D();
Ainsi, avec la première définition, le but du FAI est de " rendre la vie des classes implémentant l'interface IFat plus facile ", tandis qu'avec la seconde, le but du FAI est de " rendre la vie des clients appelant les méthodes de MyService plus facile ".
Laquelle des deux définitions différentes du FAI est réellement correcte?
@MARJAN VENEMA
1.
Ainsi, lorsque vous allez diviser IFat en une interface plus petite, quelles méthodes finissent dans quelle ISmallinterface doit être décidée en fonction de la cohésion des membres.
Bien qu'il soit logique de mettre des méthodes cohésives dans la même interface, je pensais qu'avec le modèle ISP, les besoins du client priment sur la "cohésion" d'une interface. En d'autres termes, je pensais qu'avec le FAI, nous devrions regrouper dans la même interface les méthodes nécessaires à des clients particuliers, même si cela signifie exclure de cette interface les méthodes qui devraient, par souci de cohésion, également être placées dans cette même interface?
Ainsi, s'il y avait beaucoup de clients qui ne jamais besoin d'appeler CutGreens, mais pas aussi GrillMeat, puis à respecter le modèle FAI nous ne devrions mettre à l' CutGreensintérieur ICook, mais pas aussi GrillMeat, même si les deux méthodes sont très cohésif ?!
2.
Je pense que votre confusion provient d'une hypothèse cachée dans la première définition: que les classes d'implémentation suivent déjà le principe de responsabilité unique.
Par «implémentation de classes ne suivant pas SRP», faites-vous référence aux classes qui implémentent IFatou aux classes qui implémentent ISmall_1/ ISmall_2? Je suppose que vous faites référence aux classes qui implémentent IFat? Si oui, pourquoi supposez-vous qu'ils ne suivent pas déjà le SRP?
Merci