Nous traitons les interfaces et les implémentations comme nous traitons le contenu et le style, alors pourquoi ne pas le gérer de la même façon?

Question

J'ai utilisé Spring, et j'ai regardé Guice, et je pense que ce sont deux extensions plutôt gênantes pour les langues. Je crois fermement que les langages de programmation doivent eux-mêmes s'adapter à des modèles plus cohérents avec l'injection de dépendances, les tests, etc., alors pourquoi ne pas adopter une approche basée sur une feuille de style? En autorisant plusieurs «styles», vous pouvez définir des configurations d'objets à des fins différentes. Peut-être que les classes et autres choses pourraient vous permettre de spécifier des plages de transactions plus puissantes que la simple correspondance de nom de classe/méthode.

Cela vous semble-t-il une bonne idée? En outre, pensez-vous que DI et AOP seront intégrés dans les futures langues en tant que caractéristique de base, plutôt qu'après coup? Je pensais juste, et semble être une interface -> l'implémentation correspond presque exactement aux données -> le style.

Pensées?

Answer 1

Ceci est une idée très ancienne, d'abord mis en œuvre au début des années 1980. Ensuite, il était connu par les termes "programmation de configuration", "circuits intégrés logiciels" ou "langages de description d'architecture". "Dependency Injection" est un néologisme inventé lorsque les développeurs d'entreprise ont récemment redécouvert les idées.

Par exemple, regardez les systèmes Conic [1] et Regis/Darwin [2]. Ces systèmes ont été utilisés pour écrire des logiciels de contrôle industriel et ont directement influencé la façon dont le logiciel est ** écrit pour les téléviseurs Philips. Une caractéristique intéressante de Darwin est que la langue a à la fois une représentation textuelle et graphique [3] et un formal semantics. Conic et Regis/Darwin ont fait beaucoup plus que les frameworks DI existants car ils étaient utilisés pour construire des systèmes distribués: le langage de configuration compilé dans un programme qui déployait le système en parallèle sur un réseau de machines (la sémantique formelle définit comment ce processus "d'élaboration" fonctionne). En comparaison, Spring, Guice etc. ne configurent les objets que dans un seul espace d'adressage et laissent beaucoup plus de difficultés à connecter les composants distribués au programmeur.

Une autre redécouverte de l'idée est le système d'exploitation TinyOS pour les applications de réseau de capteurs, bien que cela n'ait pas un modèle conceptuel aussi propre des composants et de la configuration.

1. Kramer, J., Magee, J., Sloman, M.S., et Lister, A., CONIQUE: une approche intégrée pour Distributed Computer Control Systems, IEE Proceedings, 130, Pt.. E, (1983), 1-10.
2. Magee, J., Dulay, N. et Kramer, J., Regis: Un environnement de développement constructif pour les programmes distribués, Distributed Systems Engineering Journal, Vol. 1, No. 5., Sept 1994, 304-312
3. Kramer, J., Magee, J., et Ng, K., Programmation de configuration graphique, IEEE Computer, 22 (10), (1989), 53- 65

** peut-être "était" maintenant.