Pourquoi les langues n'intégrerent pas l'injection de dépendance dans leur noyau (au niveau le plus bas: compilation peut-être) car les dépendances sont la racine de tout mal dans la théorie de la complexité? Cela éviterait d'utiliser des cadres.
Je suis plutôt ciblé des langues compilées.
Ma question est similaire à la dactylographie du canard qui a été introduite récemment avec la dynamique à .NET. Pourquoi pas quelque chose de similaire dans le futur pour di?
6 Réponses :
Parce que langues sont
Les dépendances ne sont pas motif: il s'agit de la complexité. Être capable d'injecter tout type de dépendance devrait être la caractéristique la plus recherchée et la plus naturelle d'une langue moderne.
RE: Modèle de conception neutre: Les deux C # et Java sont livrés avec une énorme bibliothèque de classe pouvant être considérée comme une partie de la langue, avec des éléments de collections, de lire des fichiers de configuration, des analyseurs XML, de la journalisation des bibliothèques et des couches d'abstraction de pilotes de base de données. On pourrait imaginer qu'une installation di ne serait pas totalement hors de propos ici.
Nous ne parlons pas de JDK ou de .NET Framework, nous parlons de C # ou de la langue Java . La langue est Modèle de conception neutre mais oui, JDK ou .NET framework pourrait fournir en tant que telle.
@Thilo: Bien sûr que non, et en fait di fait partie de l'API Java EE 6 (JSR 330 et 299)
@Aliostad: Les langues ne sont pas neutres de modèle de conception. Les modèles d'observateur, d'itérateur et de modèles sont cuits dans la langue C # du premier jour.
@Steven C # Langue et cadre .NET, ce sont des choses différentes. Nous parlons de C # / Java et non des autres. Pouvez-vous donner un exemple d'observateur en C #?
Iobserver a été créé dans .NET 3.5 Non?
IOBSERVER est une interface dans .NET FX ... Nous parlons de fonctionnalités de la langue.
@Aliostad: .NET Les événements sont une mise en œuvre du modèle de conception d'observateur. C # a même un mot clé pour cela: événement .
Non ils ne sont pas. Motif d'itérateur, motif observateur, modèle de pont et peu d'autres sont intégrés au noyau même de .NET
Comme Grodon dit dans les commentaires: les paramètres de fonction / méthode sont une injection de dépendance - et à peu près toutes les langues prennent en charge ceux aux niveaux les plus bas.
DI Frameworks sont généralement adaptés aux environnements de serveur. Les mécanismes de langue seraient simplement le mauvais niveau d'abstraction pour cela.
"DI Frameworks sont généralement adaptés aux environnements de serveur." Je ne suis pas d'accord! DI Frameworks peut être utilisé (et sont utilisés) pour les applications clientes, telles que Silverlight, Formulaires et WPF tout le temps.
Et j'ai oublié de mentionner les services Windows bien sûr :-)
C'est intrinsèquement une approche défectueuse. Idéalement, les langues doivent être aussi maigres que possible, mais être suffisamment puissante pour introduire des abstractions arbitraires au niveau des langues (pensez Lisp et métaprogramming). Sinon, où dessinez-vous la ligne entre quoi inclure et quoi de partir?
Quant à l'introduction d'un soutien au niveau de la compilation pour DI, c'est juste impossible. Votre application peut utiliser des bibliothèques de tri reliées dynamiquement, ce qui pourrait ne pas être connu à la compilation. Pensez les plugins.
Ils font, en fait, en vous laissant passer des paramètres aux méthodes / constructeurs / fonctions - et c'est à peu près tout ce qu'il y est, quels DI Frameworks font-ils simplement une manière fantaisie de spécifier des valeurs de paramètre.
Une question plus intéressante serait de savoir comment appliquer injection de dépendance sur un niveau de langue. Interdire statique est probablement un bon départ (comme Newspeak fait).
Si une langue est suffisamment flexible, elle peut simuler di. Java et C # ne sont clairement pas, mais les langues fonctionnelles ou hybrides sont souvent. Par exemple. Dans HASKELL, vous pouvez utiliser un lecteur monade pour contenir un "environnement" sans joindre votre code ou peut-être que vous pourriez utiliser des classes de type. Scala a une composition de mixine et des objets implicites, qui pourraient être utilisés à la fois pour cela. Donc, je conclurais qu'une langue qui a vraiment besoin DI ne manque pas de mécanismes d'abstraction appropriés et puissants.
Je peux personnellement voir le bénéfice de cela. Par exemple, j'écris le code comme celui-ci tout le temps: ne serait-il pas agréable de pouvoir l'écrire comme suit: P> public class MyService : IService
{
public MyService(private IDependency1 dep1,
private IDependency2 dep2, private IDependency3 dep3)
{
}
void IService.DoOperation()
{
using (var context = this.dep1.CreateContext())
{
this.dep2.Execute(context);
context.Commit();
}
this.dep3.Log("Success");
}
}
Ah au moins quelqu'un qui voit l'intérêt :)
Mais ce n'est pas vraiment une injection de dépendance, n'est-ce pas? Anywho, Scala résout avec élégance avec des classes paramétrées avec des arguments du constructeur.
@Gustafc: L'exemple montre une injection de constructeur, qui est une forme spécifique (la forme la plus courante) d'injection de dépendance.
PHP est une langue de script. Je cible plutôt des langues compilées.
Parce que les utilisateurs de cette langue ne seraient pas en mesure de se trembler comme des enfants sur quel cadre était le mieux. Sérieusement, imaginez ce qui se passerait si quelqu'un est arrivé avec une meilleure approche du modèle X (dans ce cas DI) que celui des outils de langue?
Mon point n'est pas un cadre afin qu'il ne se pose aucune question parce qu'il serait naturel :)
@ user310291 - Non, les gens ne feraient que discuter de la mise en œuvre de la langue du motif ! Un modèle peut être mis en œuvre à bien des égards; Il n'y a pas de mauvaise ou de mauvaise manière. Cela conduit à la subjectivité et donc à toute tentative d'une langue pour mandater que cela soit fait 'de cette façon seulement' va simplement apporter l'argument sur le cadre jusqu'à la langue entière! En parlant de subjectivité, c'est probablement pourquoi cette question sera fermée dans les prochaines minutes! Bien que la réponse d'Aliostad, pour moi, le tour.
Off Sujet: Le typing de canard a été dans .NET depuis le premier jour. Par exemple, tout objet qui a une méthode Getenumerator () peut être utilisé avec une boucle de foresach, il ne a pour implémenter iEnumérable ..
Mais tout objet n'a pas un getenumerator () :)
C'est vrai, quel est ton point?