2009-04-23 8 views
18

Les méthodes du constructeur dans les interfaces sont-elles mauvaises?méthodes constructeur dans les interfaces

+4

Puisque vous ne pouvez pas instancier une interface, comment l'utiliseriez-vous? –

+2

Je veux dire spécifier un constructeur dans une interface. –

+0

Suppression de l'étiquette subjective. Il ne semble y avoir rien de subjectif dans cette question. – JaredPar

Répondre

2

Qu'elles soient ou non mauvaises, je ne connais aucun langage permettant de spécifier un constructeur sur une interface. Cela dit, personnellement, je ne crois pas que le constructeur d'un objet fasse partie de l'interface de cet objet et, en tant que tel, l'ajout d'un constructeur à une interface inhiberait la flexibilité naturelle offerte par les interfaces.

+7

Il est tard, mais PHP a cette capacité. (Cela ne fait pas une caractéristique qui vaut la peine d'avoir, mais c'est seulement mon opinion.) – lotsoffreetime

12

Ils sont mauvais en ce sens qu'ils ne servent à rien. À la base, une interface est simplement un contrat de transmission de données. Il n'y a pas d'implémentation attachée à une interface et donc il n'y a rien à initialiser et pas besoin de constructeur.

Si vous avez besoin d'une sorte d'initialisation, il vaut mieux utiliser une classe abstraite.

+6

Btw, je pense, l'interface est plus que "simplement le transfert de données contrat". Il devrait être considéré comme un contrat de responsabilité qui, à son tour, inclut la spécification de signature. – isntn

+3

@isntn, à la base de tout, une interface ne spécifie pas comment transmettre les données. La seule pensée qui garantit le comportement sont les contrats et les cadres de test. Les interfaces peuvent impliquer un comportement mais elles ne peuvent pas le garantir – JaredPar

+0

Je suis d'accord avec JaredPar. Si vous avez le constructeur dans votre interface, il semble que vous ayez besoin d'une classe abstraite. Vous obtiendrez un comportement commun pour les composants implémentant cette interface, au moins pour les méthodes setter/getter liées aux variables passées à la méthode __construct, donc vous devriez aller, IMO, à une classe abstraite dans ce contexte. –

4

Bien que les interfaces ne puissent pas avoir de constructeurs dans la plupart des langues, le Factory pattern fournit un contrat pour la construction d'objets, similaire à une interface. Jetez un coup d'oeil à ça.

36

Pourquoi les gens pensent-ils que quelqu'un veut instancier l'interface? Ce que nous voulons faire est de forcer les implémenteurs à implémenter le constructeur, tout comme les autres méthodes d'interface.

Une interface est comme un contrat. Disons que j'ai une interface Queue, et je veux m'assurer que les implémenteurs créent un constructeur avec un argument, ce qui crée une file d'attente singleton (Une nouvelle file d'attente avec juste cet élément). Pourquoi cela ne devrait-il pas faire partie du contrat? Avec au moins les interfaces Java, cela ne peut pas être spécifié.

+12

+1 Alors, non, ils ne sont pas mauvais. "Pourquoi les gens pensent-ils que quelqu'un veut instancier l'interface?" D'accord, l'OMI le PO ne le demandait pas. Si une classe requiert une valeur chaque fois qu'elle est instanciée (disons, une classe wrapper), il me semble qu'un contrat de transmission de données peut être utile. Particulièrement en PHP où les méthodes ne peuvent pas être remplacées - le constructeur est "bloqué" dans un certain comportement. – Ben

+4

Les méthodes peuvent être surchargées en PHP mais pas surchargées. –

+2

Peut-être que @Steve faisait référence à l'obligation de faire correspondre la signature du constructeur. – XedinUnknown

5

Tout d'abord, je ne suis pas d'accord que l'interface est juste un contrat de transmission de données. Si cela était vrai, vous seriez autorisé à définir des propriétés dans une interface.

Je ne pense pas exactement c'est bizarre de faire quelque chose comme:

interface IDBConnection 
{ 
    function __construct($connectionString); 
    function executeNonQuery($commandText, $paramters=null); 
    function executeScalar($commandText, $paramters=null); 
    function executeSingle($commandText, $paramters=null); 
    function executeArray($commandText, $paramters=null); 
} 

Cela vous permettra de créer des instances de classes de tiers pour l'accès aux données sur la base de la simple réflexion au lieu d'être simplement un contrat de données. Je suis assez sûr que ce n'est pas le meilleur exemple, j'irais pour une classe de base abstraite ici dans le monde réel, mais je suis également assez sûr qu'il existe des raisons parfaitement valables pour définir un constructeur contrat de méthodes dans une interface à laquelle je n'ai pas pensé.

Je ne l'ai pas vu fait, mais je ne pense pas que ce soit bizarre ou mauvais.

Questions connexes