Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java: Design, Quality, Testing > Стандарты названий пакетов

Автор: JDmitry 9.4.2013, 11:34

Как вы обычно именуете пакеты в своем проекте? Например мы используем:

x.x.dao - интерфейсы для ДАО
x.x.dao.impl - их реализации
x.x.entity - сущности для базы данных
x.x.service - интерфейсы для сервисов
x.x.dto - Data Transfer Objects
x.x.enums - все enumы
и прочее

Есть какие-то общепринятые соглашения по названию пакетов в зависимости от их цели и функциональности? (Java convetion этого не содержит)
И как вы разделяете свой проект?

Автор: LSD 10.4.2013, 10:29

Цитата(JDmitry @ 9.4.2013, 12:34

)

Есть какие-то общепринятые соглашения по названию пакетов в зависимости от их цели и функциональности?

Здравый смысл smile

Пакеты нужны людям, не Java. Я руководствуюсь соображем что человек посмотрев на структуре пакетов понял где искать классы ответвенные за некий функционал. С этой точки зрения пакет x.x.enums лишен смысла чуть более чем полностью, если руководствоваться подобной логикой то и интерфейсы надо в x.x.interfaces smile

А вообще посмотри на JDK как там классы разложены.

Автор: vanarchi 16.8.2013, 13:09

Просматривал недавно из Clean Code Роберта Мартина серию Episode 7 Architecture, Use Cases, and High Level Design.

Там он советует, чтобы структура проекта (в том числе и пакеты) отражала архитектуру. Архитетура это то, что отражает не то как программа сделана (механизмы), а её назначение.

Структура

Цитата

x.x.dao - интерфейсы для ДАО
x.x.dao.impl - их реализации
x.x.entity - сущности для базы данных
x.x.service - интерфейсы для сервисов
x.x.dto - Data Transfer Objects
x.x.enums - все enumы

классифицирует как раз механизмы, а не назначение различных подсистем.

Приемущества классификации механизмом в том, что они конкретны, конечны и их можно легко классифицировать и даже стандартизировать.

Недостатки такой классификции:

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

Как переходный вариант решения проблемы
- разбить системы на модули (границы или boundaries описанные в статье http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) , в каждом из которых пакеты именуются по механизмам реализации: например

//Модель
com.компания.приложение.domain.model

//API
com.компания.приложение.domain.service.dept
com.компания.приложение.domain.service.emp

//Варианты реализации API
com.компания.приложение.domain.service.dept.impl
com.компания.приложение.domain.service.emp.impl

com.компания.приложение.web.service
com.компания.приложение.web.service.impl

com.компания.приложение.web.dto
com.компания.приложение.web.dto.factories
com.компания.приложение.web.views
com.компания.приложение.web.filters

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

Автор: EvilsInterrupt 30.11.2013, 23:01

Цитата(vanarchi @ 16.8.2013, 14:09

)

классифицирует как раз механизмы, а не назначение различных подсистем.

В этой книге дан совет располагать не "по назначению", а согласно "где программист(он или его коллега) будет искать". Другими словами, если в проекте по механизмам, то и надо раскладывать по механизмам.

Иначе:
Идеальной структуры нету! Все зависит от ситуации, проекта, coding-style и многих прочих других факторов.

Совет:
Когда Вы ощутите себя нашедшим класс и с мыслью в голове "Никогда бы не подумал, что он тут", то спросите себя "А где то самое первое место откуда я начал поиск?", ну или "какое второе место, куда я посмотрел?". Кладите Ваши вещи туда, где Вы их начинали искать, вполне возможно что и в след. раз Вы тоже начнете искать с тех мест! ;) Однако прежде чем положить в новое место спросите себя: "А почему начал поиск именно от туда?". Также помогают вопросы к коллегам: "Где бы ты стал искать класс.... ?"