Модуль мудрого развития в Java

Question

Я собираюсь разработать настольное приложение Java, которое я хотел бы сохранить в модуле, поэтому мне легко настроить его. Например, давайте возьмем биллинговую систему. Сейчас я могу разделить его на несколько модулей

1. Учет
2. Billing
3. печати Билл
4. Email Билл

Если кто-то сказал мне: «Мне не нужно, чтобы напечатать Билла », то я могу удалить модуль« Печатный счетчик »и так далее.

Я видел в некоторых приложениях (C++), где они были разработаны как отдельные приложения и как-то объединены.

В Java, что является лучшим способом модульной разработки? Лучший способ, который я знаю, - создавать пакеты и управлять вещами через интерфейсы.

Независимо от того, что бы это ни было, основным преимуществом было бы свести к минимуму усилие при появлении настроек. Каковы предложения?

Answer 1

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

Быстрый пример, основанное на ваших:

• пакет клиент позволит манипулировать клиент
учета
• пакета будет обрабатывать информацию о счете клиента и зависит от клиента
• пакета биллинг будет обрабатывать биллинг и зависит на клиентском (или бухгалтерском учете?)
• пакет billing.receipt будет обрабатывать получение и зависит от выставления счета (и косвенно на клиента)
• pa ckage billing.receipt.printing будет обрабатывать квитанцию ​​и будет зависеть от выставления счета и получения платежа (и опосредованно по фактурированию и клиенту).
• пакет billing.receipt.email будет обрабатывать рассылку электронной почты для отправки и в зависимости от выставления счетов (и косвенно на выставление счетов и клиент)

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

Answer 2

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

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

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

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

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

Answer 3

Отделите детали на артефакты, встроенные в многочисленные jar s. Скрыть все, что находится за интерфейсами. Затем выполните проект «приложение», используя все необходимые артефакты и интегрируя их вместе. Используйте инструмент управления зависимостями, например Maven или Gradle, чтобы собрать все вместе, а Spring - интегрировать модули в полученное приложение.

Для настольного приложения вы можете использовать некоторую платформу, например Eclipse RCP или Netbeans RCP - у них есть своя собственная система плагинов и инфраструктура интеграции/интеграции.