Je sais ce que la mise en œuvre d'une interface signifie (techniquement), mais je ne sais pas si je comprends ce que le "contrat" englobe:
permet de dire que je fais une classe myList quels implements java.util.list (c'est-à-dire que je implémente toutes les méthodes avec le code qui compile) est myList A liste alors? Ou dois-je lire tous les commentaires des méthodes que je remplacerai et assurez-vous que ma mise en œuvre remplit ces "attentes" sur le comportement?
4 Réponses :
Techniquement, oui, Si je reçois une liste Imaginez que vous vendez des voitures. Je vais dans votre magasin et j'achète une voiture. Pour moi, c'est une voiture parce que cela ressemble à toutes les autres voitures: il a des roues, des pédales, des fenêtres, etc. Mais si j'appuie sur l'accélérateur, il freine et quand je tourne des lumières, et quand j'arrive, et quand j'ouvre le Windows, il accélère et tue un pauvre enfant sur la route, je ne serai pas heureux du tout et vous serez en difficulté parce que la voiture que vous avez vendue ne vous comporte pas correctement. myList est une liste si elle implémente toutes les méthodes de la liste list . Mais le compilateur n'est pas un magicien. Il ne peut pas vérifier que vos méthodes font ce qu'ils devraient faire. Et bien sûr, chaque méthode devrait faire ce que sa documentation dit qu'il fait.
, et cette liste est une instance de myList , et j'appelle list.add (" foo ") , je m'attends à ajouter" FOO "à la fin de la liste. Ne pas être enlevé, ni ajouté deux fois, ou quel que soit autre comportement. Donc, bien sûr, si votre classe implémente , ses méthodes doivent être conformes au contrat défini dans sa documentation de l'API.
Haha est excellent exemple +1
Alors, il n'y a donc pas de moyen officiel de savoir si ma mise en œuvre est "droite" ou "fausse", cela semble assez vague, tout sur les attentes (informelles). Ce serait bien si l'interface / la classe abstraite est livré avec un test d'unité qui décide si la classe d'exécution remplit toutes les attentes. Actuellement, la documentation de l'API pourrait changer, rendant ma mise en œuvre soudainement invalide (sans mes connaissances).
Le JDK ne fournit pas un tel test unitaire. C'est à vous de le mettre en œuvre. Mais le contrat ne changera jamais: cela briserait tout le code Java existant là-bas. La mise en œuvre d'une collection standard n'est pas une tâche commune du tout. Le JDK et les bibliothèques communes telles que GUAVA, fournissent tout ce dont vous avez besoin pour 99,999% des cas d'utilisation. Je ne peux pas remettre à mettre en œuvre une collection standard une fois dans mes 20 années de programmation Java.
@RAPHAELROTH Un moyen simple de faire est de même que Python: vous pouvez inclure des exemples d'utilisation dans la documentation et vous pouvez les exécuter en tant que tests. Cependant, cela est en fait assez fragile. La "voie réelle" de faire cela serait envers les méthodes formelles et fournirait des preuves au compilateur que les méthodes satisfont aux propriétés requises par l'interface. Il existe des langues qui font cela.
En Java, la différence entre une classe et une interface est qu'une classe a des implémentations de méthode. Une interface ne le fait pas. Donc, une interface peut avoir une méthode add (), mais ne dirait rien de savoir comment ajouter des travaux. Une classe devrait définir comment ajouter des travaux.
Vous implémentez une interface au moment où vous mettez Et oui, vous devez lire tous les commentaires et vous assurer que votre classe implémente l'interface de la manière attendue. Sinon, vous vous retrouverez avec quelque chose qui compile mais peut ne pas fonctionner correctement. implémente interfacename dans votre définition de classe. Vous devez ensuite définir toutes les méthodes de l'interface ou votre application ne compilera pas. Ensuite, oui, il serait correct de dire que MyClass est une myInterface- vous pouvez même aller d'une interface MyInterface = nouveau myClass ();
Corrigé cela avant même de poster ceci :)
Euh..java 8+ permet la mise en œuvre sur l'interface. Limité, mais est possible.
L'interface est un minimum nécessaire pour le contrat: comme vous le dites, s'il ne compile pas, vous ne pouvez pas avoir rempli le contrat! Mais la langue peut ne pas être en mesure de définir et de limiter les exigences complètes de l'interface, de sorte que vous devriez également répondre à ces attentes.
Un exemple facile est l'interface alors vous avez rempli le contrat de langue, et peut-être que votre contrat de classe "aussi. Mais si votre classe contient une liste , vous surprendrez vos utilisateurs: "Cela n'a pas Comprend également les attentes des utilisateurs. Brisez-les, et bien qu'un avocat de langue puisse dire que votre classe est: une liste iclonable . Si tout ce que vous faites est implémenter Clone () Droite!" , d'autres ne sont pas d'accord ..
Quel est le iClonable -Interface dont vous parlez? Java.lang.clonable est un marqueur -Interface et ne vous oblige pas même à remplacer clone () . Mais vous avez raison, interfaces de marqueur ( sérialisable Serait un autre exemple populaire) n'existe que comme une sorte de promesse de remplir le contrat - il est trivial de mettre en œuvre une compilation de mise en œuvre, mais sans remplir également le contrat, il est inutile.
est myList une liste?
Pour répondre à cette question, vous devez d'abord comprendre quelles interfaces font ou quelles sont-elles écrites pour ...
Ne pas oublier les interfaces peut vous offrir un détachement très important entre ce qu'est une classe
peut faire et comment ils le font ... Donc, la mise en œuvre technique d'une interface ne consiste pas à demander si un objet est quelque chose mais plus sur la demande comment un objet peut faire quelque chose Alors, quand vous dites liste myContainer = nouvelle arraylist (); Vous définissez un objet qui peut faire toutes les choses qu'une liste peut faire ... ajouter, supprimer, obtenir etcsc
Vous pouvez le dire une liste, je dirais que cela peut faire ce qu'une liste peut faire ..
MyList est-il une liste? Oui
@Enzokie donc je dois mettre en œuvre
ajouter pour ne rien faire etobtenir pour toujours renvoyer null, vous l'appeleriez toujours une liste?Tant que vous implémentez la liste, il est encore appelé une liste. À la fin de la journée, c'est votre décision si vous avez mis quelque chose sur ces méthodes mises en œuvre ou lancez une exception non prise en charge, le fait reste toujours que cela s'appelle toujours une liste.