Quand je vois des extraits de code tels que
interface A {
void a();
void b() default { System.out.println("b"); };
void c() final { System.out.println("c"); };
}
5 Réponses :
Je crois que le concept de "méthodes d'extension" n'est pas plus que la dernière chance de pirater / corriger des API mal conçues qui ont été exposées au "monde externe". Juste sucre syntaxique.
Ouais toutes ces API mal conçues dont les concepteurs n'étaient pas douées de clairvoyance ou ne pouvaient pas réellement concevoir leur interface différemment, car certaines fonctionnalités n'existaient pas déjà;)
Les concepteurs d'API @Voo n'ont pas besoin d'être clairVoyant pour se rendre compte qu'il pourrait y avoir des méthodes à ajouter plus tard. Aurait pu utiliser des classes abstraites, bien que la langue soit déficiente en ce sens qu'elle n'autorise pas la définition d'une classe abstraite "pure" sans ajouter les bagages indésirables de compatibilité binaire d'une interface.
Oh, "méthodes de défenseur" en fait.
@TOMHAWTIN utilisant des classes abstraits n'est pas seulement problématique d'un point de vue pratique, mais également de mauvais codage de style OOP assez souvent. Donc, clairement, ce n'est pas une solution pour beaucoup de situations.
@Voo aurait été parfaite pour collections, JDBC, etc. comme pour le mauvais style, il est clair que c'est quelque chose qui ne va pas avec le "style" s'il provoque ces types de problèmes. Oh, et quels problèmes pratiques ?? AbstractCollection doit aller, et vous allez utiliser java.lang.reflect.proxy , mais qui se soucie.
@TOMHAWTIN Problèmes pratiques? Eh bien, il est impossible d'implémenter plus de 2 "interfaces" qui limite certainement. Et dans les interfaces générales, les interfaces sont beaucoup plus utilisées que les classes abstraites, la modification est la bienvenue pour beaucoup de personnes et de personnes qui préfèrent que les classes abstraites ne sont pas touchées. Le changement élimine simplement l'un des problèmes les plus gênants avec des interfaces (spécifiez-nous maintenant les constructeurs aussi et je serais heureux).
Implémenter plus de 2 interfaces? Est-ce souvent que vous souhaitez hériter d'une collection ou d'une instruction type avec une autre classe?
Nous avons besoin de cela parce que cela fera de la scala les gars absolument furieux. Ils ont déjà une fonctionnalité assez similaire en forme de «traits», alors ils devront maintenant faire fonctionner ces travaux avec ceux-ci.
Pisser sur Scala Gars est littéralement la priorité la plus élevée dans le développement de la langue Java.
En réalité, je pense que les méthodes d'extension virtuelle sont un très Mise en œuvre incomplète de traits, et pourrait se peindre dans un coin.
C'est génial parce que cela vous permet, le rédacteur d'API d'après-hoc étendre les interfaces sans causer de Noschmethoderrors. Vous fournissez également des implémentations par défaut pour les méthodes de V2 pour les classes compilées contre la V1; Le code fonctionne comme un charme. Cela vous permet également de remplacer la mise en œuvre par défaut dans les classes compilées contre V2 comme d'habitude et effectue des interfacces numérotées redondantes. Je considère qu'il est également supérieur aux méthodes d'extension d'utilisation.
Non, c'est une aide aux écrivains de la bibliothèque, qui peut désormais étendre leurs interfaces (API) en V1.1 sans avoir besoin de le renommer à 2.0 et nécessitant un recompilement.
Ah, excuses - c'est un outil pour les écrivains de bibliothèque qui facilitent l'évolution de l'API des bibliothèques; Les écrivains de bibliothèque peuvent étendre leurs interfaces sans que les utilisateurs de la bibliothèque ont besoin de modifier leur code.
Il est prévu que Java 8 contiendra une forme de soutien de Lambda et de fermeture, ce qui constituerait une grande étape dans la modernisation de la langue Java. Le problème est que les bibliothèques existantes basées sur des interfaces, telles que le cadre de collecte, ne pourront pas utiliser directement ces nouvelles fonctionnalités. Il n'est pas possible d'ajouter une méthode à une interface sans casser les implémentations existantes, elles ne compileraient plus.
Avoir Lambdas, mais ne pouvant pas les utiliser facilement avec des collections standard, constituerait une énorme déception des développeurs Java. Pour intégrer Lambdas dans les collections standard, des méthodes telles que La solution à ce problème consiste à ajouter une autre fonctionnalité, des méthodes d'extension, qui définissent une implémentation par défaut d'une méthode dans une interface. Les sous-classes existantes utiliseraient la méthode par défaut, mais il est également possible de remplacer la méthode avec une meilleure mise en œuvre spécialisée et éventuelle.
Plus d'informations sur la méthode de l'extension Proposition peut être trouvée à Proposition d'amélioration Java 126 . foreach , mapper ou filtre seraient hautement souhaitables.
Et pour exactement les mêmes raisons pour lesquelles ils seront très utiles pour Lambdas, ils aideront également les autres API. Enfin no interface x , x2 , .. plus! À propos du temps.
Je vous suggère de regarder cette conférence: http://medianetwork.oracle.com/media / show / 16999
Cela explique tout. La chose la plus intéressante à faire est de permettre à une interface d'évoluer sans rééchapper votre base de code. Ceci est la clé pour permettre à une grosse basebase d'évoluer et de ne pas devenir de plus en plus criblé.
C'est une excellente extension de l'OMI, rapprochera Java du monde de l'héritage multiple sans tous ses détails de mise en œuvre désordonnés.
@Perception "... sans tous ses détails de mise en œuvre désordonnés ..." Comment exactement?
Constructeur chaînage, nom potentiel d'affrontement, ambiguïté polymorphe, pas trop parler de la complexité supplémentaire qui devrait être définie dans le compilateur. Toutes les raisons pour lesquelles les mélanges sont plus populaires que multiples héritages dans beaucoup de langues modernes et ce que cette fonctionnalité me rappelle plus.
@Perception Désolé, j'ai demandé comment éviter tout ce genre de choses, pas ce que c'est le problème.
Pas de problème de chaînage de constructeur car il n'y en a pas. Et je suppose qu'ils ajouteront une portée explicite pour remplacer les méthodes d'interface pour éviter le problème de nommage / polymorphe d'ambiguïté.
Peu de gens utilisent Java 7 et nous nous inquiétons de Java 8?
@Sobolan comme programmeur Java, je dois m'inquiéter de choses comme ça.
C'est une caractéristique que les concepteurs de l'API aimeront et qui n'a pas à craindre beaucoup le programmeur moyen. Et vraiment? Java est l'une des langues modernes les plus fondamentales. Heck Même C ++ avait plus de changements au cours des dernières années que Java. Obtenir au moins Lambdas et le soutien de la fermeture réelle est une longue attente.
@VOO Vous n'allez pas voir des fermetures «réelles» ou «pures» dans JDK8. Autre que nécessaire «Syntaxtical Sugar», le comportement n'est différent que des classes intérieures de manière particulière.
@Tom attendez-vous que nous ne retirons pas la limitation de ne pas étendre la portée des variables extérieures? J'espère certainement que ce n'est pas vrai, mais je n'ai pas regardé le JSR. Ça avait anticlimalactique ~
Qu'est-ce que vous voulez dire? Les règles de portée sont comme des classes intérieures anonymes. Il n'y a pas de intérieure cela. Les locaux extérieurs référencés ne doivent pas nécessairement être marqués final, mais doivent être utilisés comme si elles sont (en effet, la finale est implicite).
@RADU 1. Beaucoup de personnes utilisent Java 7. Si vous êtes sur Java EE 6 ou que vous développez des applications Java Core, vous devez l'utiliser. 2. L'amélioration continue est nécessaire pour suivre .NET, rubis et autres langues. Peu importe la ralentissement de votre commande, Java doit toujours publier une nouvelle version tous les 18 mois à 2 ans.
@Glenbest Regardez l'horodatage de mon commentaire. Évidemment, les choses ont changé un peu depuis. En ce qui concerne le fait que Java devrait libérer plus fréquemment afin de rester compétitif: je suis tout à fait d'accord. 2 ans semble un bon équilibre pour cela. J'espère qu'elles s'en tiendront à l'avenir, car jusqu'à maintenant c'était un peu décevant: 4 ans et demi de Java 6 à Java 7 et il y aura 2 ans et 8 mois de Java 7 à Java 8 à Java 8 ....