это - Как я должен структурировать приложение Java, где я помещаю свои классы?




классы методы объекты (7)

Используйте пакеты для группировки связанных функций.

Обычно вершина вашего дерева пакетов - это ваше доменное имя, измененное ( com.domain.subdomain ), чтобы гарантировать уникальность, и тогда обычно будет пакет для вашего приложения. Затем разделите это на связанную область, поэтому ваша FileStorageStrategy может войти, скажем, в com.domain.subdomain.myapp.storage , а затем могут быть конкретные реализации / подклассы / любые в com.domain.subdomain.myapp.storage.file и com.domain.subdomain.myapp.storage.database . Эти имена могут быть довольно длинными, но import держит их всех в верхней части файлов, и IDE также могут помочь в этом.

Исключения обычно идут в том же пакете, что и классы, которые их бросают, поэтому, если бы у вас было, скажем, FileStorageException оно было бы в том же пакете, что и FileStorageStrategy . Точно так же интерфейс, определяющий константы, будет в одном пакете.

В действительности нет такого стандарта, просто используйте здравый смысл, и если все становится слишком грязным, рефакторинг!

Прежде всего, я знаю, как создать Java-приложение. Но я всегда был озадачен тем, где поставить свои занятия. Есть сторонники для организации пакетов строго ориентированным образом, другие - отдельными.

У меня всегда были проблемы с

  • именование,
  • размещение

Так,

  1. Где вы помещаете свои специфичные для домена константы (и как лучшее название для такого класса)?
  2. Где вы кладете классы для вещей, которые являются как инфраструктурными, так и специфичными для домена (например, у меня есть класс FileStorageStrategy, который хранит файлы либо в базе данных, либо, альтернативно, в базе данных)?
  3. Где помещать Исключения?
  4. Существуют ли какие-либо стандарты, на которые я могу ссылаться?

Названия классов всегда должны быть описательными и понятными. Если у вас есть несколько доменов ответственности за ваши классы, то их, вероятно, нужно будет реорганизовать.

Точно так же для вас пакеты. Они должны быть сгруппированы по областям ответственности. У каждого домена есть свои исключения.

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


Мне нравится разбивать классы на пакеты, связанные друг с другом.

Например: Модель Для вызовов, связанных с базой данных

Просмотр классов, которые касаются того, что вы видите

Классы функциональности Control Core

Util Любой разное. классы, которые используются (как правило, статические функции)

и т.п.


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

/src - for your packages & classes
/test - for unit tests
/docs - for documentation, generated and manually edited
/lib - 3rd party libraries
/etc - unrelated stuff
/bin (or /classes) - compiled classes, output of your compile
/dist - for distribution packages, hopefully auto generated by a build system

В / src я использую шаблоны Java по умолчанию: имена пакетов, начинающиеся с вашего домена (org.yourdomain.yourprojectname) и имена классов, отражающие аспект OOP, который вы создаете с помощью класса (см. Другие комментаторы). Также полезны такие общие имена пакетов, как util , model , view , events .

Я склонен ставить константы для определенной темы в собственном классе, например SessionConstants или ServiceConstants, в том же пакете классов домена.


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


Краткий ответ: нарисуйте свою системную архитектуру с точки зрения модулей, нарисованных бок о бок, каждый модуль нарезается вертикально на слои (например, просмотр, модель, настойчивость). Затем используйте такую ​​структуру, как com.mycompany.myapp.somemodule.somelayer , например com.mycompany.myapp.client.view или com.mycompany.myapp.server.model .

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

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

  • com.mycompany.myapp.view
  • com.mycompany.myapp.model
  • com.mycompany.myapp.services
  • com.mycompany.myapp.rules
  • com.mycompany.myapp.persistence (или «dao» для уровня доступа к данным)
  • com.mycompany.myapp.util (остерегайтесь, чтобы это использовалось так, как если бы оно было «разным»)

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


Мне действительно понравилось стандартное расположение макетов Maven.

Одна из ключевых идей для меня состоит в том, чтобы иметь два исходных корня: один для производственного кода и один для тестового кода:

MyProject/src/main/java/com/acme/Widget.java
MyProject/src/test/java/com/acme/WidgetTest.ava

(здесь как src / main / java, так и src / test / java являются исходными корнями).

Преимущества:

  • В ваших тестах есть доступ к уровню (или «по умолчанию») для тестируемых классов.
  • Вы можете легко упаковать только ваши источники в JAR, сбросив src / test / java в качестве исходного корня.

Одно эмпирическое правило о размещении и пакетах классов:

Вообще говоря, хорошо структурированные проекты будут свободны от круговых зависимостей . Узнайте, когда они плохие (а когда нет ), и рассмотрите инструмент JDepend или SonarJ , который поможет вам устранить их.





architecture