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

10

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

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

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

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

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

Владимир Слепнев
источник
То, как вы формулируете свой вопрос, я предполагаю, что вы имеете в виду поток данных в одном процессе, а не межпроцессное взаимодействие. Итак, какую проблему вы видите, которая не может быть решена стандартными механизмами отправки / прослушивания событий?
Док Браун
Придуманный пример: представьте, что в глубине вашей системы есть некоторый код, который отправляет пользователю текстовое сообщение. И вы получаете новое требование, чтобы текст сообщения зависел от текущего времени в часовом поясе пользователя. Вызов стека выглядит следующим образом: некоторый код, который знает часовой пояс пользователя, вызывает метод, который вызывает метод, который (... повторяется 15 раз) вызывает метод, который генерирует текст сообщения. Это простой пример по моим стандартам, потому что он предполагает общение только в нисходящем направлении, но вы все равно должны изменить сигнатуры 15 методов, чтобы внести свои тривиальные изменения.
Владимир Слепнев
Ну, я думаю, что может помочь, это явно моделировать поток данных и отделять компоненты от потока данных. Немецкий инженер-программист много пишет на эту тему, большинство статей на немецком языке. Вот статья о нем на английском языке: geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/…
Док Браун,
Я думаю, что единый внутренний API может помочь. Он был бы доступен во всем приложении и содержал бы всю логику получения данных.
СуперМ

Ответы:

1

Вы имеете в виду 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 носят существующие языки как плащ, который дает им все гибкие возможности, которые вы упомянули. Мне нравится называть это подсознанием моей программы, заботясь о грязной работе без проблем.

Сеньор разработчик
источник
Очереди сообщений могут быть излишними, но обмен сообщениями - это идеальный способ для передачи событий по всем направлениям. Java использует Message Driven Beans (MDB), и это должно позволить вашей программе отправлять или получать «разговоры» друг с другом. Вы можете сделать это таким образом для асинхронного бонуса.
Сеньор Разработчик
Спасибо за указатели! Это определенно заставляет задуматься, как мог бы выглядеть язык, если бы он был спроектирован с нуля для поддержки внедрения зависимостей и подобных шаблонов.
Владимир Слепнев
0

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

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

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

Крис Траверс
источник
Спасибо за ответ! Мне кажется, что исследование языка программирования может помочь с этой проблемой. Например, если код читает некоторые данные из глобальной базы данных или из спрятанных синглетонов, может быть статическая / декларативная гарантия того, какие данные ему требуются.
Владимир Слепнев
-1

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

hairy flow of control

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

user127749
источник
Почему отрицательный голос? В цитате пропущено вступление, которое в точности поддерживает мою точку зрения: «(вероятно, оно классифицируется как« Антипаттерн »или« Запах кода »и поэтому имеет название в соответствующих кругах, но я не знаю, поэтому я буду оставьте это безымянным) "
user127749
2
Это на самом деле не ответ на вопрос, это, вероятно, причина понижения
Даниэль Гратцер
Тогда позвольте мне перефразировать вопрос: есть ли какая-то волшебная уловка, чтобы устранить беспорядок в коде, который нарушает один из самых основных принципов разработки программного обеспечения: ПОЦЕЛУЙ (оставайся простым, глупым)? Уловка не волшебная, это либо программист, который не может быть заменен, потому что он знает все неочевидные детали (которые убьют компанию в долгосрочной перспективе), либо реструктурирует базу кода. К сожалению, многие компании изначально не заботятся о правильном дизайне кода или даже не понимают его последствий, а затем приходится переписывать свой код хотя бы один раз, многие даже переписывают его много раз ...
user127749