Можем ли мы упростить добавление потоков данных между удаленными частями большой кодовой базы?

При внесении изменений в большие системы я часто сталкиваюсь с проблемой, заключающейся в том, что какой-то части функциональности требуется получить некоторые данные из другой части, но они находятся в разных частях глубокого и ветвящегося дерева вызовов, возможно, проходящего через прослушиватели событий, отложенные вызовы, и т.д. Таким образом, простое изменение может быстро появиться.

Соответствующая цитата из поста Йосси Крейнина в блоге по адресу http://www.yosefk.com/blog/i-want-a-struct-linker.html :

У вас есть какая-то структура данных, которую вы часто передаете. Вскоре самое ценное в структуре - это не данные, которые она хранит, а тот факт, что она доступна на всех этапах контроля.

Глобальные переменные - это один из классических способов позволить коду «кричать» удаленному коду, но они, как известно, проблематичны. Переменные с динамической областью действия являются более ограниченным способом, но они также проблематичны.

Есть ли какие-либо исследования языка программирования, направленные на решение этой проблемы? Можем ли мы упростить добавление непредвиденных потоков данных в большую кодовую базу, сохраняя при этом статическую проверку, простое модульное тестирование и другие полезности?

Вы имеете в виду CDI (внедрение зависимостей контекста) AKA IoC (инверсия контроля). Java JSF и Spring Framework являются некоторыми примерами. ASP.NET MVC имеет плагины, такие как Unity. Javascript начинает организовывать структуры с использованием таких библиотек, как RequireJS, поведение внедрения которого наблюдается во многих современных средах JS. Это для подключения локальных и удаленных приложений.

Для слабой связи между сетями компании предпочитают использовать веб-сервисы с SOAP, REST, AJAX или регулярные удаленные вызовы методов с помощью RPC. В Java вы можете использовать JAX-WS или .NET WCF для создания распределенных сервисов. Затем вы выстраиваете их в служебную шину или «поток данных» с любого языка или платформы в качестве клиента. Ruby, Python, Scala, Java, C #, ... все что угодно.

Слабое связывание позволяет вам разделять и преодолевать проблемы, а сервисы часто являются точкой входа в базу данных для извлечения данных. Поднявшись по лестнице, у нас есть зверь под названием Очередь сообщений. Эта дорога ведет к структурам типа предприятия и инфраструктуры.

Если ваш проект настаивает на отсутствии сети, существуют такие языки, как Scala, Akka, NodeJS и т. Д., Которые предназначены для большого потока данных в одном приложении. Они также работают с некоторыми или всеми ранее упомянутыми технологиями для сложных проектов. Например, Scala можно использовать с сервисами JAX-RS REST для извлечения вида «глобальных данных» из источника данных и иметь Spring для внутренней проводки IoC. В JBoss, .NET и GUI-инструментах, таких как MuleESB, есть также множество бизнес-сред для выполнения или рабочих процессов. В процессе разработки Eclipse и Netbeans позволяют перетаскивать сервисы на экран визуальной блок-схемы.

Наконец, у Java все еще есть компоненты Singleton. Для настройки ваших методов во время выполнения используйте прокси или фреймворки. Но, честно говоря, это так 1999.

Если вы делаете так много звонков, чтобы отправить пользователю сообщение в зависимости от его часового пояса, то, по моему мнению, возможно, есть двухэтапный способ достижения того же эффекта, который видит пользователь. Но да, каркасы CDI носят существующие языки как плащ, который дает им все гибкие возможности, которые вы упомянули. Мне нравится называть это подсознанием моей программы, заботясь о грязной работе без проблем.

Самый простой способ сделать это в больших масштабах - это использовать некоторый API для инкапсуляции данных. Это может быть хранилище NoSQL или инкапсулированная RDBMS (или это может быть как в разное время, так и в одном и том же приложении) - нет никаких причин, почему вы не можете иметь RDBMS для долгосрочной обработки хранение и управление базами данных NoSQL для управления краткосрочным состоянием). Это может быть даже серия одноэлементных объектов.

Ваши структуры данных могут затем быть доступны в каком-то нейтральном пространстве, в некоторой степени управляемым способом. Это подход, который мы используем с LedgerSMB (но с несколькими полуглобальными переменными для того, что по сути является спрятанными синглетонами, но опять-таки они управляемые, мы выбрали непосредственное запоминание объекта, потому что это немного облегчило управление переменными, но есть все 4 из них).

Конечно, любой подход имеет компромиссы, и вы не можете обойти эти компромиссы. Ключ заключается в том, чтобы взглянуть на компромиссы (управление против производительности, чистота кода против потенциальных ошибок кодирования) и принять решение на основе того, что лучше для вашего приложения.

Если вы используете (или цитируете) слова

hairy flow of control

тогда я предполагаю, что ваш код действительно беспорядок. Вы должны бросить это немедленно. Если вы используете модульность / разделение проблем, не существует такого понятия, как «волосатый поток контроля». Вашему коду просто не хватает простоты, что также вытекает из того факта, что вы ссылались на глобальные переменные :-).