Эффективная связь между объектами Java

Question

Я занимаюсь разработкой фреймворка для создания эффективных приложений любых размеров. Приложения состоят из модулей (приложение тоже модуль), и для меня важна производительность. Я знаю, что существуют рамки для модульности и т. Д., Но мне нужно было реализовать свою собственную. Хотя я задумался о производительности отдельных модулей и оптимизировал их, связь между объектами (и между потоками) - это то, что я не могу решить, как реализовать. Вот некоторые варианты, которые я рассмотрел:

• НИО трубы
• События (регистрация слушателей)
• Очереди транзакций в контексте приложения

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

Answer 1

Мое единственное, что я могу посоветовать, - не иди этим путем. Как уже сказал Билл К., большинство реализаций будут значительно быстрее и более полными. Еще более важно то, что есть прекрасные ресурсы для достижения того, что вы пытаетесь сделать: например, OSGi, которая имеет Eclipse и Glassfish v3 под своим поясом.

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

Answer 2

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

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

Answer 3

i am developing a framework for creating efficient applications in all sizes

Чтобы дать очень общий совет, я бы предложил вам погрузиться в исходный код jboss, чтобы получить представление о том, как все делается, когда они должны работать (возможно, самая старая версия, которую вы можете получить, в качестве отправной точки) *

Answer 4

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

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

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

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

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

Наконец, внедрив собственную платформу, вы, скорее всего, создадите много дополнительных работ по обслуживанию в будущем для команды / компании. Вы ошибаетесь, и ваши коллеги будут проклинать вас по коридорам в течение следующих 10 лет. Даже если вы на 100% правильно используете среду, кто-то в вашей организации все равно должен поддерживать ее в течение всего срока службы приложений, которые от нее зависят.