Мы относимся к интерфейсам и реализациям так же, как к контенту и стилям, так почему бы не обработать их аналогичным образом?

Question

Я использовал Spring, и я изучил Guice, и я думаю, что оба они являются довольно навязчивыми расширениями для языков. Я твердо верю, что сами языки программирования должны адаптироваться к шаблонам, более согласованным с внедрением зависимостей, тестированием и т. Д., Так почему бы не использовать подход, основанный на таблицах стилей? Допуская несколько «стилей», вы можете определять конфигурации объектов для разных целей. Возможно, классы и другие полезные свойства позволят вам указать диапазоны транзакций, более мощные, чем простое сопоставление имен классов / методов.

Это кому-то кажется хорошей идеей? Кроме того, считаете ли вы, что DI и AOP будут интегрированы в будущие языки в качестве основной функции, а не запоздалая мысль? Я просто подумал, и кажется, что интерфейс -> реализация соответствует почти точно -> стиль.

Мысли

Answer 1

Это очень старая идея, впервые реализованная в начале 1980-х годов. Тогда это было известно терминами «программирование конфигурации», «программные интегральные схемы» или «языки описания архитектуры». «Внедрение зависимостей» - это неологизм, придуманный, когда корпоративные разработчики недавно заново открыли для себя идеи.

Для примера посмотрите системы Conic [1] и Regis / Darwin [2]. Эти системы использовались для написания программного обеспечения для промышленного управления и оказали непосредственное влияние на то, как программное обеспечение ** написано для телевизоров Phillips. Интересной особенностью Darwin является то, что язык имеет как текстовое, так и графическое представление [3] и формальную семантику .

Conic и Regis / Darwin сделали намного больше, чем существующие структуры DI, потому что они использовались для построения распределенных систем: язык конфигурации скомпилирован в программу, которая развернула систему параллельно через сеть машин (формальная семантика определяет, как это действует процесс "разработки"). Для сравнения, Spring, Guice и т. Д. Только конфигурируют объекты в одном адресном пространстве и оставляют гораздо большие трудности с подключением распределенных компонентов к программисту.

Еще одним открытием этой идеи является операционная система TinyOS для приложений сенсорных сетей, хотя она не имеет столь же чистой концептуальной модели компонентов и конфигурации.

1. Kramer, J., Magee, J., Sloman, M.S., и Lister, A., CONIC: интегрированный подход к распределенным компьютерным системам управления, IEE Proceedings., 130, Pt. E, (1983), 1-10.
2. Magee, J., Dulay, N. и Kramer, J., Regis: конструктивная среда разработки для распределенных программ, Distributed Systems Engineering Journal, Vol. 1, № 5., сентябрь 1994 г., 304-312
3. Крамер Дж., Маги Дж. И Нг К., Программирование графической конфигурации, IEEE Computer, 22 (10), (1989), 53-65.

** Может быть, "был" сейчас.