#java #algorithm #reflection #pipeline
#java #алгоритм #отражение #конвейер
Вопрос:
Как бы вы предложили реализовать следующий сценарий. У меня есть несколько мыслей, но ни одна из них не удовлетворяет мою проблему в целом, поэтому я хотел бы получить ваш вклад.
Я создаю тип приложения с рабочим потоком. Пользователь создает конвейер действий, который затем необходимо выполнить. Проблема, с которой я сталкиваюсь, заключается в следующем. Каждый «виджет» в конвейере должен определять, что он может принимать в качестве входных данных, и что он будет выдавать на выходе. Он может принимать любое количество входных «потоков», а также выдавать несколько «потоков» выходных данных. Теперь возникает проблема. Они должны быть динамическими. Например, кто-то должен иметь возможность написать плагин для приложения, в котором он определяет свой собственный виджет со входами и выходами. Но другие виджеты должны иметь возможность подключаться к нему, чтобы они могли отправлять свои выходные данные в новый или получать входные данные от него.
Как следует поступить, чтобы, во-первых, предоставить список допустимых входных и выходных данных, и, во-вторых, как я могу вычислить, какой метод вызывать в виджете. Например, если я хочу отправить выходные данные из моего виджета в новый, мне нужно иметь возможность вычислить, существует ли приемлемый метод получения (в этом случае их может быть несколько), и, во-вторых, мне нужно знать метод, который нужно вызвать, чтобы передать данные.
Я взглянул на закрытие, делегаты и т.д., Которые, похоже, способны делать то, что мне нужно. Просто подумал, что сначала я получу еще немного входных данных.
Спасибо.
Ответ №1:
Я бы посоветовал вам обеспечить, чтобы все ваши компоненты реализовывали один или несколько интерфейсов, позволяющих другим компонентам и платформе использовать эти интерфейсы для опроса компонента о том, что он может отправлять и что он может получать.
Это сделает ваш код более надежным и потребует меньше магии для работы.
Комментарии:
1. Что вы думаете о следующем? Что я думал, что сделаю, так это приведу в исполнение контракт с любыми третьими сторонами с интерфейсом, который просит их вернуть коллекцию класса-оболочки, которую я определяю. Эта оболочка в основном содержит немного метаданных, включая имя метода и параметры, которые он предоставляет. Тогда я могу просто получить к нему доступ через отражение.
2. Не используйте отражение. Вместо этого используйте интерфейсы.
3. Есть ли какая-либо причина не использовать отражение? Это достаточно просто. И вызовы выполняются нечасто, поэтому производительность не должна быть проблемой. Или я что-то упускаю?
4. Отражение подразумевает, что вы находитесь за пределами фактического кода в пути, например, представляя имена классов в виде строк, потому что если бы вы этого не делали, вам не нужно было. Посмотрите на различные механизмы создания зависимостей и их долгую борьбу за улучшение этого, чтобы уйти от XML-файлов с именами классов. Не используйте отражение, если подойдут интерфейсы.
Ответ №2:
Взгляните на архитектуры, управляемые сообщениями, и Mule ESB.