Wir behandeln Schnittstellen und Implementierungen, wie wir Inhalte und Stile behandeln, also warum nicht so ähnlich umgehen?

Question

Ich habe Spring verwendet, und ich habe Guice untersucht, und ich denke, dass dies beides eher aufdringliche Erweiterungen von Sprachen sind. Ich bin der festen Überzeugung, dass Programmiersprachen selbst sich an Muster anpassen müssen, die stärker auf Abhängigkeitsinjektionen, Tests usw. abgestimmt sind. Warum also nicht zu einem auf Stylesheets basierenden Ansatz greifen? Indem Sie mehrere "Stylings" zulassen, können Sie Konfigurationen von Objekten für verschiedene Zwecke definieren. Vielleicht könnten Sie Klassen und andere Güteklassen Ihnen erlauben, Bereiche von Transaktionen zu spezifizieren, die mächtiger sind als einfache Klassen-/Methoden-Namensvergleiche.

Scheint das für jemanden eine gute Idee? Glauben Sie auch, dass DI und AOP als Kernmerkmal in zukünftige Sprachen integriert werden und nicht als Nachsatz? Ich habe nur gedacht, und scheint wie Schnittstelle -> Implementierung entspricht fast genau mit Daten -> Stil.

Gedanken?

Answer 1

Dies ist eine sehr alte Idee, die zuerst in den frühen 1980er Jahren eingeführt wurde. Dann war es unter den Begriffen "Konfigurationsprogrammierung", "Software-integrierte Schaltkreise" oder "Architekturbeschreibungssprachen" bekannt. "Dependency Injection" ist ein Neologismus, als Unternehmensentwickler die Ideen vor kurzem wiederentdeckten.

Schauen Sie sich zum Beispiel die Systeme Conic [1] und Regis/Darwin [2] an. Diese Systeme wurden zum Schreiben industrieller Steuerungssoftware verwendet und beeinflussten direkt, wie Software für Phillips-Fernseher geschrieben wird. Ein interessantes Merkmal von Darwin ist, dass die Sprache sowohl eine textliche als auch eine grafische Darstellung [3] und eine formal semantics aufweist.

Conic und Regis/Darwin haben viel mehr als bestehende DI-Frameworks, weil sie verwendet wurden, um verteilte Systeme zu konstruieren: die Konfigurationssprache in einem Programm kompiliert, das das System parallel über ein Netzwerk von Maschinen implementiert (die formale Semantik definiert wie dieser "elaboration" Prozess funktioniert). Im Vergleich dazu konfigurieren Spring, Guice usw. nur Objekte in einem einzigen Adressraum und lassen die größeren Schwierigkeiten, verteilte Komponenten mit dem Programmierer zu verbinden, zu.

Eine weitere Neuentdeckung der Idee ist das Betriebssystem TinyOS für Sensornetz-Anwendungen, obwohl das Konzeptmodell von Komponenten und Konfiguration nicht so sauber ist.

1. Kramer, J., Magee, J., Sloman, M. S. und Lister, A., CONIC: Ein integrierter Ansatz zur Distributed Computer Control Systems, IEE Proceedings, 130, Pt.. E, (1983), 1-10.
2. Magee, J., Dulay, N. und Kramer, J., Regis: Eine konstruktive Entwicklungsumgebung für verteilte Programme, Distributed Systems Engineering Journal, vol. 1, Nr. 5, September 1994, 304-312,
3. Kramer, J., Magee, J., und Ng, K., Graphische Konfigurationsprogrammierung, IEEE Computer, 22 (10), (1989), 53- 65.

** vielleicht "war" inzwischen.