J'ai généralement rencontré beaucoup, beaucoup plus de problèmes de maintenance associés à des interfaces pures que des ABC, même des ABC utilisés avec un héritage multiple. YMMV - dunno, peut-être que notre équipe les a juste mal utilisés.
Cela dit, si nous utilisons une analogie du monde réel, dans quelle mesure y a-t-il des interfaces pures complètement dépourvues de fonctionnalité et d’état? Si j'utilise l'USB comme exemple, c'est une interface raisonnablement stable (je pense que nous sommes maintenant à l'USB 3.2, mais elle a également maintenu une compatibilité ascendante).
Pourtant, ce n'est pas une interface sans état. Ce n'est pas dépourvu de fonctionnalité. Cela ressemble plus à une classe de base abstraite qu'à une interface pure. C'est en fait plus proche d'une classe concrète avec des exigences fonctionnelles et d'état très spécifiques, la seule abstraction étant ce qui se branche sur le port étant la seule partie substituable.
Sinon, il s'agirait simplement d'un "trou" dans votre ordinateur avec un facteur de forme normalisé et des exigences fonctionnelles beaucoup plus souples qui ne feraient rien par lui-même jusqu'à ce que chaque fabricant propose son propre matériel pour faire en sorte que ce trou fasse quelque chose, puis cela devient un standard beaucoup plus faible et rien de plus qu'un "trou" et une spécification de ce qu'il doit faire, mais pas de disposition centrale sur la façon de le faire. En attendant, nous pourrions nous retrouver avec 200 façons différentes de le faire après que tous les fabricants de matériel essaient de trouver leurs propres moyens pour associer fonctionnalité et état à ce "trou".
Et à ce stade, certains fabricants pourraient présenter des problèmes différents de ceux des autres. Si nous devons mettre à jour la spécification, nous pourrions avoir 200 implémentations concrètes de ports USB avec des manières totalement différentes d'aborder la spécification, de la mettre à jour et de la tester. Certains fabricants peuvent développer de facto des implémentations standard qu'ils partagent entre eux (votre classe de base analogique implémentant cette interface), mais pas tous. Certaines versions peuvent être plus lentes que d'autres. Certains pourraient avoir un meilleur débit mais une latence plus faible ou vice versa. Certains pourraient utiliser plus de batterie que d'autres. Certains risquent de s'effondrer et de ne pas fonctionner avec tout le matériel censé fonctionner avec des ports USB. Certains pourraient nécessiter la mise en place d’un réacteur nucléaire, ce qui a tendance à donner à ses utilisateurs un empoisonnement par rayonnement.
Et c'est ce que j'ai trouvé, personnellement, avec des interfaces pures. Dans certains cas, ils peuvent avoir un sens, par exemple simplement pour modéliser le facteur de forme d’une carte mère par rapport à un boîtier de processeur. Les analogies des facteurs de forme sont en effet à peu près sans état et dépourvues de fonctionnalité, comme dans le cas du "trou" analogique. Mais j’estime souvent que c’est une grave erreur pour les équipes de considérer cela comme étant supérieur dans tous les cas, même pas proche.
Au contraire, je pense que beaucoup plus de cas seraient résolus par ABC que par les interfaces si ce sont les deux choix possibles, à moins que votre équipe soit si gigantesque qu’il soit souhaitable de disposer de l’analogique supérieure à 200 implémentations USB concurrentes plutôt qu’une norme centrale. maintenir. Dans une ancienne équipe dans laquelle je faisais partie, je devais en réalité me battre pour assouplir la norme de codage afin de permettre les ABC et l'héritage multiple, principalement en réponse aux problèmes de maintenance décrits ci-dessus.