Pourquoi voulez-vous déclarer une Interface et ensuite instancier un objet avec Java?

Un ami et moi, nous étudions Java. Nous étions à la recherche à des interfaces d'aujourd'hui et nous avons eu un peu d'une discussion sur la façon dont les interfaces sont utilisées.

L'exemple de code mon ami m'a montré contenait ceci:

IVehicle modeOfTransport1 = new Car();
IVehicle modeOfTransport2 = new Bike();

Où IVehicle est une interface qui est mis en œuvre dans les catégories auto et moto.
Lors de la définition d'une méthode qui accepte IVehicle comme un paramètre, vous pouvez utiliser les méthodes d'interface, et lorsque vous exécutez le code au-dessus des objets de travail comme d'habitude. Toutefois, cela fonctionne parfaitement bien lors de la déclaration de la voiture et de vélo comme vous le feriez normalement comme ceci:

Car modeOfTransport1 = new Car();
Bike modeOfTransport2 = new Bike();

Donc, ma question est, pourquoi voudriez-vous utiliser l'ancienne méthode au cours de la dernière lors de la déclaration et l'instanciation de la modeOfTransport objets? Est-il question?

Donc ce qui arrive si vous voulez écrire une méthode qui prend soit une Voiture ou un Vélo comme un paramètre? Maintenant ce qui?
vous pouvez poster les méthodes sur la IVechical interface? Ce qui se passe lorsque vous souhaitez gérer un nouveau type d'objet ie Bus ou SpaceRocket
beaucoup de réponses ont été downvoted. downvoters, le soin d'expliquer pourquoi?
un grand nombre de réponses n'ont tout simplement pas répondre à la question.
D'accord, trop de downvotes sur des réponses raisonnables!
Je vais vous expliquer mon downvotes: tout le monde ici semble lancer dans une explication sur le polymorphisme ou le but des interfaces, qui n'est pas ce que l'OP a demandé à propos. L'OP a une question sur si immédiatement jeté à un type d'interface ou de report de la coulée jusqu'à ce que plus tard.
7 de 10 réponses reçues 2 downvotes. De ceux qui n'ont, la plupart ne s'adresse la question. En tout cas, je serait impossible de les décrire comme pas utile (les critères établis pour downvote).
non, il n'est pas. Il a été demandé spécifiquement "pourquoi voudriez-vous utiliser l'ancienne méthode au cours de la dernière". Il ne fait même pas mention de la coulée.
Je suis juste en indiquant la cause probable. (Je n'ai pas downvote tout.)
L'OP n'a pas été demandé pourquoi utiliser une interface plus d'un type de béton. L'OP a été demandé, "pourquoi définir les variables de cette façon, au lieu de cette façon", ce qui pour moi est la même chose que de demander, "implicite fonte maintenant, ou plus tard?"
Je ne crois pas que c'est une déduction logique. Les deux sont très différents.
Quelle horrible logique de sauter! Terrible raison de downvote. Vous devriez avoir honte.
Je suis curieux de voir quelle réponse est acceptée! Je suis d'accord que le fait d'être potentiellement hors sujet n'est pas une raison pour voter, tant que la réponse elle-même est exacte.
Je devrais être beaucoup de choses.
Merci à Tous, la réponse à ces questions et à la discussion m'a beaucoup aidé, j'ai marqué la bonne basé Sur le vote plus élevé. Mis à part cela je ne pouvais pas décider entre Larry Watanabe ou Oscar Gomez postes. Je suis d'accord que certaines réponses semblent avoir été inutilement vers le bas voté. Merci encore.

InformationsquelleAutor bot_bot | 2011-10-10

9

Il n'a pas d'affaire là.

Là où cela compte vraiment est dans les autres interfaces qui en ont besoin pour fonctionner sur IVehicle. Si ils acceptent des paramètres et valeurs de retour comme IVehicle, le code sera plus facilement extensible.

Comme vous l'avez remarqué, une de ces objets peut être transmis à une méthode qui accepte IVehicle en tant que paramètre.

Si vous aviez le code suivant qui a utilisé la Voiture ou à Vélo, des opérations spécifiques qui ont été utilisés, alors il serait avantageux de les déclarer à la Voiture ou à Vélo. La Voiture et le Vélo opérations spécifiques seraient disponibles pour chacun des objets pertinents, et les deux devraient être utilisable (c'est à dire peut être transmis) comme IVehicle.
- +1 - Il n'a pas d'importance hors de la méthode à l'aide de la IVehicle ce type de la variable est déclarée en tant que, tant qu'il implémente IVehicle. Je pense que le "meilleur" exemple de vraiment voir la puissance des interfaces avec l'injection de dépendance.
- Je crois que l'une des raisons pour lesquelles il est préconisé de les déclarer comme IVehicle la place de la Voiture ou de la Moto est précisément pour éviter d'avoir le code suivant vous mentionner que l'utilisation de la Voiture ou de Vélo opération spécifique. De telles choses causer des douleurs intenses lors d'un refactoring pour changer entre les types de véhicule parce que vous avez placé une dépendance à un type particulier de véhicule. Il ne suffit pas de passer dans et hors de méthodes, c'est à propos de l'état d'esprit que vous êtes en tant que développeur et si vous êtes d'écrire du code plus facile à maintenir.
- Si plus tard dans le code que vous vouliez, par exemple, échanger les valeurs stockées dans modeOfTransport1 et modeOfTransport2, alors ce serait une bonne chose que vous avez déclaré comme interface instances plutôt que sur des cas concrets.
InformationsquelleAutor Larry Watanabe
13

Il y a un gros plus sur les déclarant à l'aide de l'interface, qui est ce qui est connu comme "codage d'une interface" au lieu de "codage pour une mise en œuvre" qui est un grand Conception Orientée objet (OOD) principe, de cette façon, vous pouvez déclarer une méthode comme ceci:
```
public void (IVehicle myVehicle)
```
et ce sera d'accepter n'importe quel objet qui implémente cette interface, puis à l'exécution, il fera appel à la mise en œuvre comme ceci:
```
public void (IVehicle myVehicle)
{
    myVehicle.run() //This calls the implementation for that particular vehicle.
}
```
Pour répondre à la question initiale, pourquoi voudriez-vous utiliser un sur l'autre, il y a plusieurs raisons:

1) Déclarant à l'aide d'une interface, signifie que vous pouvez plus tard substituer cette valeur avec une autre classe qui implémente cette interface, au lieu d'être enfermé dans cette classe de béton

2) Vous permet de profiter pleinement de polymorphisme en les déclarant à l'aide d'une interface, parce que chaque application peut appeler la méthode correcte au moment de l'exécution.

3) Vous suivez les INONDATIONS principe de code à une interface
- Je suis désolé, mais ceci ne répond pas à la question. L'affiche est de poser des questions sur pourquoi vous ne pourriez jamais le faire IInterface var = new ConcreteClass();, pas la façon dont les interfaces de travail.
- Oui je suis conscient de cela, je suis en expliquant qu'en les déclarant à l'aide d'une interface, de la programmation d'une interface non de mise en œuvre, et qui peuvent être utiles, comme sur l'exemple ci-dessus.
- Ce n'est pas le point, OP sait sur les interfaces. Vous n'êtes pas aborder quelque chose au sujet de pourquoi vous voulez déclarer une variable locale comme un IInterface quand vous savez que son béton de classe. Ce que vous avez posté fonctionne exactement de la même manière dans les deux scénarios, les OP exposés.
InformationsquelleAutor Oscar Gomez
5

Vous êtes vraiment se poser: quelle référence dois-je utiliser?

Généralement que vous souhaitez utiliser comme général un type de référence que possible que vous offre l'accès à le comportement que vous avez besoin. Cela signifie une des interfaces ou des classes parent de votre type de béton, plutôt que le type de béton lui-même. Bien sûr, ne prenez pas ce point de trop loin, par exemple, vous ne voulez certainement pas à déclarer tout comme un Object!

Tenir compte de ces options:
```
Set<String> values1 = new TreeSet<String>();
TreeSet<String> values2 = new TreeSet<String>();
SortedSet<String> values3 = new TreeSet<String>();
```
Tous les trois sont valables, mais généralement la première option de values1 est mieux parce que vous serez en mesure d'accéder le comportement de la Set interface, de sorte que plus tard, vous pouvez échanger dans une autre mise en œuvre assez facilement:
```
Set<String> values1 = new HashSet<String>();
```
Méfiez-vous de l'utilisation de la deuxième option values2. Il vous permet d'utiliser le comportement spécifique de l' TreeSet mise en œuvre de telle manière que la permutation dans une mise en œuvre différente de Set devient de plus en plus difficile. C'est très bien tant que c'est votre but. Donc, dans votre exemple, l'utilisation d'un Car ou Bike de référence uniquement lorsque vous avez besoin d'accéder à quelque chose qui n'est pas dans le IVehicle interface. Sachez cependant que le suivant ne marche pas:
```
TreeSet<String> values2 = new HashSet<String>(); //does not compile!
```
Encore il ya des moments où vous avez besoin d'accéder à des méthodes qui ne sont pas dans le type. Ceci est illustré dans la troisième option values3 -- la référence est plus spécifique que Set, qui vous permet de compter sur le comportement de SortedSet plus tard.
```
TreeSet<String> values3 = new ConcurrentSkipListSet<String>();
```
La question sur les types de référence s'applique non seulement lorsque les variables sont déclarées, mais aussi dans les méthodes où vous devez spécifier le type de chaque paramètre. Heureusement, "l'utilisation générale d'un type de référence que possible" la règle de base s'applique pour les paramètres de la méthode, trop.
- Je crois que c'est la meilleure réponse ici. Le point est que quand vous regardez la déclaration de la variable, vous savez exactement comment il sera utilisé dans le code. En gardant types aussi général que possible, est un outil d'analyse et de codage guide. C'est somehwat source de confusion pour les gens qui n'ont pas eu à se décomposer le code écrit par d'autres, très souvent, mais une fois qu'elle vous a aidé à résoudre un problème, la question devient "Pourquoi voudriez-vous jamais utilisez PAS le type)
- Je pensait sans doute, trop!
InformationsquelleAutor jtoberon
3

Programme d'une interface plutôt qu'une mise en œuvre.

Lorsque vous programmez à une interface vous permettra d'écrire du code qui peut gérer tout type de Véhicule. Donc à l'avenir de votre code, sans modification, doit travailler avec les Trains et les Avions.

Si vous ignorez l'interface, puis vous êtes coincé avec les Voitures et les Vélos, et tous les nouveaux Véhicules supplémentaires seront nécessaires modifications du code.

Le principe derrière cela est:

Ouverte à l'Extension, Fermée à la Modification.
- Je ne peux pas imaginer pourquoi cela (et bien d'autres sur ce fil) remporté DEUX votes contre. C'est tellement clair et concis, donne exactement ce que l'information est importante pour le développement de solides code.
- Je serais ravi de voir un utile exemple de code plutôt que de buzzphrases, mais il ne mérite PAS deux downvotes.
- Beaucoup de gens ont été brûlés par des mauvaises implémentations--travailler avec des équipes qui abusent des interfaces, peut-être en les forçant sur chaque classe, dans le cadre d'une équipe exigence dans un code qui n'a probablement même pas de mandat tant de la structure. Cela provoque beaucoup de frusteration et de sur-réaction. Il n'y a pas beaucoup à faire à ce sujet: ils ont à acquérir plus d'expérience avant de vraiment l'obtenir. En attendant, une bonne réponse voté en bas et en arrière jusqu'à zéro peut être un ÉNORME rep gain, donc ne vous sentez pas trop mal pour les auteurs 🙂
InformationsquelleAutor Vincent Ramdhanie
3

Parce que vous n'avez pas vraiment attention à ce que la mise en œuvre est... seulement ce qu'il a un comportement.

Disons que vous avez un animal
```
interface Animal {
    String speak();
}

class Cat implements Animal {

    void claw(Furniture f) { /* code here */ }

    public String speak() { return "Meow!" }
}

class Dog implements Animal {

    void water(FireHydrant fh) { /* code here */ }

    public String speak() { return "Woof!"; }
}
```
Maintenant, vous voulez donner à votre enfant un animal de compagnie.
```
Animal pet = new ...?
kid.give(pet);
```
Et vous le récupérer plus tard
```
Animal pet = kid.getAnimal();
```
Vous ne voulez pas aller
```
pet.claw(favorateChair);
```
Parce que vous ne savez pas si l'enfant avait un chien ou pas. Et vous n'avez pas de soins. Vous ne le sais --Animaux-sont autorisés à parler. Vous ne savez rien à propos de leurs interactions avec les meubles ou les bouches d'incendie. Vous savez que les animaux sont pour la parole. Et il rend votre fille rire (ou pas!)
```
kid.react(pet.speak());
```
Avec cela, quand vous faites un poisson rouge, le kid de réaction est assez boiteux (s'avère goldfishes ne parle pas!) Mais quand vous les mettez dans un ours, la réaction est assez effrayant!

Et tu ne pouvais pas faire cela si vous avez dit
```
Cat cat = new Cat();
```
parce que vous êtes de te limiter les capacités d'un Chat.
- Curieux de savoir comment cela (et bien d'autres) a beaucoup de downvotes. Semble un peu etrange, pour être honnête.
InformationsquelleAutor corsiKa
2

Honnêtement votre argument est plutôt discutable. Ce qui se passe ici est une conversion implicite d'un IVehicle. Vous et votre ami semble faire valoir que c'est mieux de le faire immédiatement (comme pour le premier exemple de code), ou plus tard (lorsque vous appelez la méthode, comme dans le deuxième exemple de code). De toute façon, ça va être implicitement converti en IVehicle, la vraie question est donc: avez-vous besoin pour faire face à une Voiture, ou tout simplement un Véhicule? Si vous avez besoin d'un IVehicle, la première manière est parfaitement bien (et préférable si plus tard vous souhaitez vous connecter de manière transparente à changer de voiture pour un vélo). Si vous avez besoin de la traiter comme une voiture à d'autres points dans votre code, puis il suffit de laisser comme une voiture.
- Je ne peux pas parler pour les OP ami, mais je crois que l'idée est que les développeurs doivent être en évitant de avoir à la traiter comme une voiture" chaque fois que possible. Par l'instanciation d'un Vehicle au lieu d'un Car, vous forcez les gens à penser en termes d'un Vehicle. De cette façon, lorsque vous remplacez votre Car avec un Plane, qui seront très certainement se produire au cours de la durée de vie de votre application, vous n'avez pas (le répète, N') refactoring de le faire.
- Pour citer einstein: "Rendre les choses aussi simples que possible, mais pas plus." Utiliser une interface aussi souvent que vous le pouvez, mais croyez-le ou non, il ya des moments où vous avez besoin pour traiter une voiture comme une voiture. Si c'est le cas, une interface n'est pas approprié.
- Ce n'est pas tellement un argument comme essayer de comprendre ce que nous faisons. Mon compagnon compris le code ci-dessus, nous voulons juste de comprendre les implications de chaque option.
- Il y a des moments, oui. Mais ces moments doivent être évités. Quel avantage avez-vous obtenir par le traitement d'une seule voiture comme une voiture au lieu d'un véhicule? Si vous avez des moments où vous êtes le traitement d'une voiture comme une voiture au lieu d'un véhicule, alors vous avez probablement fait une erreur dans votre conception.
- les voitures ont des moteurs. Les vélos ne sont pas. Il est tentant de dire "laisser l'objet de gérer lui-même", mais -- combien de fois un moteur de fixer lui-même? Non, une bonne conception, on aurait toujours la possibilité d'avoir un objet extérieur en étant conscient de Car ojbects (peut-être un CarMechanic objet). La modularité et les interfaces sont bonnes, mais vous n'avez encore besoin de provision pour la spécialisation.
- Non, ils ne sont pas vraiment. Quand était la dernière fois que vous aviez à faire une méthode de prendre un HashSet au lieu d'un Set? Jamais. Pourquoi? Parce qu'il a été bien conçu. La modularité et les interfaces sont bonnes, et de la spécialisation est indicative d'une primitive de comprendre le problème.
- Vous avez raison, les véhicules doivent fixer leurs propres moteurs. Mon erreur.
- selon votre conception, Voiture et Avion devrait être complètement différent de copier et de coller des implémentations. Le problème, c'est que vous n'avez pas à créer un "Moteur" de l'interface ainsi que des Véhicules (en Supposant que vous ne voulez pas de simplement mettre un hasEngine() la méthode sur votre véhicule, l'autre solution raisonnable).
InformationsquelleAutor Chris Eberle
1

De déclarer des interfaces et de l'instanciation d'entre eux avec des objets permet un concept puissant appelé le polymorphisme.
```
List<IVehicle> list = new ArrayList<IVehicle>();
list.add(new Car());
list.add(new Bike());

for (int i = 0; i < list.size(); ++i)
    list.get(i).doSomeVehicleAction();   //declared in IVehicle and implemented differently in Car and Bike
```
Explicitement de répondre à la question: il convient d'utiliser une déclaration d'interface (même si vous connaissez le type de béton), de sorte que vous pouvez passer plusieurs types (qui implémentent la même interface) à une méthode ou d'une collection; alors le comportement commun à la mise en œuvre de chaque type peut être appelé n'importe ce que le type réel est.
- Bon, quelqu'un pourrait expliquer pourquoi je suis downvoted?
- Je ne suis pas de la downvoters, mais je soupçonne qu'ils ont été motivés par votre dernier paragraphe. Vous prétendez répondre à l'OP de la question, c'est pourquoi le les variables locales peut-être a déclaré que les objets de l'interface plutôt que des objets concrets. Votre raison-de sorte que vous pouvez passer plusieurs types d'une méthode ou d'une collection--n'a pas de sens. Une variable déclarée comme Car peut être transmis à une méthode ou d'une collection qui accepte un IVehicle. Il n'est pas nécessaire à tous ce qu'il soit déclaré comme un IVehicle.
InformationsquelleAutor Platinum Azure
1

bien les interfaces sont les comportements et les classes sont à leur mise en œuvre, il y aura plusieurs reprises par la suite quand vous programme où vous ne pouvez connaître les comportements(de l'interface). et pour les utiliser il vous permettra de mettre en œuvre pour obtenir des avantages hors de lui. il est essentiellement utilisé pour cacher les détails d'implémentation de l'utilisateur que de leur dire le comportement(l'interface).

InformationsquelleAutor Ali Raza
0

Votre intuition est correcte; le type d'une variable doit être aussi précis que possible.

C'est différent de la méthode des types de retour et les types de paramètre; il y a de l'API concepteurs veulent être un peu abstrait donc, l'API peut être plus flexible.

Variables ne font pas partie de l'Api. Ils sont des détails de mise en œuvre. L'Abstraction n'est généralement pas s'appliquer.
- "l'Abstraction en général ne s'applique pas" -- abstraction assez souvent s'applique à des variables locales. Cela dépend vraiment de la façon dont les variables vont être utilisés. Si, par exemple, il y a des raisons plus tard dans le code pour remplacer les références stockées dans modeOfTransport1 et modeOfTransport2, puis en les déclarant comme interface instances plutôt que des cas concrets est nécessaire.
InformationsquelleAutor irreputable
-2

Avec "IVehicle modeOfTransport1 = new Voiture();", les méthodes appartenant uniquement en Voiture ne sont pas accessibles à modeOfTransport1. Je ne sais pas la raison de toute façon.
- Ce qui est faux. L'objet qui est créé est toujours une instance de Car. La référence stockée dans modeOfTransport1 peut être converti en un Car (si vous arrivez à savoir que cette instance particulière de IVehicle est, en fait, un Car) et tous les Carinstance spécifique méthodes, sont disponibles.
- sans la coulée, comme demandé dans la question d'origine, vous pouvez appeler spécifiques à la Voiture des méthodes d'instance?
- Non, pas sans casting, mais ce n'était pas mon point. Je critique votre demande OP code "uniquement instancier les méthodes de l'interface, mais pas de la Voiture méthodes...Ils pourraient conduire à différentes utilisation de la mémoire." c'est peut-être pas ce que vous vouliez, mais vous êtes clairement en disant que new Car() se comporte (ou peut avoir un comportement) de façon différente en fonction de ce qui est sur le côté gauche de l'instruction d'affectation, et qui n'est tout simplement pas vrai.
- Oui. Qui devrait être à mon hypothèse. C'est la seule possibilité que je pense. Je pensais que si une voiture de l'objet est instancié, pourquoi nous ne pouvons pas l'appeler propres méthodes. Savez-vous comment tester l'utilisation de la mémoire pour ces deux objet la création de moyens? En outre, ce "casting" n'en interne? Je suis un Java débutant. Merci pour votre aide.
- Vous pouvez utiliser instanceof pour tester si une référence peut être converti en particulier de la classe ou de l'interface. Lorsque vous déclarez IVehicle thing = new Car(), la raison pour laquelle vous ne pouvez pas appeler Cardes méthodes est que vous, ou, plutôt, le compilateur n'a pas savoir que thing arrive à être un Car (même si elle est), parce qu'il n'est pas déclaré une voiture. Toutefois, vous pouvez utiliser if (thing instanceof Car) { /* cast to Car and call car-specific methods */ }. Notez que la conversion d'une variable de référence à un autre type n'apporte aucune modification à l'objet référencé par lui-même, juste pour la référence.
InformationsquelleAutor RobinSun

Vous devez vous connecter pour publier un commentaire.