Модераторы: LSD
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Стандарты названий пакетов, На какие пакеты вы разделяете проект 
V
    Опции темы
JDmitry
Дата 9.4.2013, 11:34 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 45
Регистрация: 5.3.2009

Репутация: нет
Всего: нет



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

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 этого не содержит) 
И как вы разделяете свой проект?
PM MAIL   Вверх
LSD
Дата 10.4.2013, 10:29 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Leprechaun Software Developer
****


Профиль
Группа: Модератор
Сообщений: 15708
Регистрация: 24.3.2004

Репутация: 1
Всего: 537



Цитата(JDmitry @  9.4.2013,  12:34 Найти цитируемый пост)
Есть какие-то общепринятые соглашения по названию пакетов в зависимости от их цели и функциональности?

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


--------------------
Disclaimer: this post contains explicit depictions of personal opinion. So, if it sounds sarcastic, don't take it seriously. If it sounds dangerous, do not try this at home or at all. And if it offends you, just don't read it.
PM MAIL WWW   Вверх
vanarchi
Дата 16.8.2013, 13:09 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Новичок



Профиль
Группа: Участник
Сообщений: 1
Регистрация: 16.8.2013

Репутация: нет
Всего: нет



Просматривал недавно из 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 описанные в статье The Clean Architecture) , в каждом из которых пакеты именуются по механизмам реализации: например

//Модель
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

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

Это сообщение отредактировал(а) vanarchi - 16.8.2013, 13:24
PM MAIL   Вверх
EvilsInterrupt
Дата 30.11.2013, 23:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Executables research
***


Профиль
Группа: Завсегдатай
Сообщений: 1019
Регистрация: 14.7.2007
Где: Железнодорожный, МО, Россия

Репутация: нет
Всего: 9



Цитата(vanarchi @  16.8.2013,  14:09 Найти цитируемый пост)
классифицирует как раз механизмы, а не назначение различных подсистем.

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

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

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


PM MAIL WWW ICQ Jabber   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | Java: Design, Quality, Testing | Следующая тема »


 




[ Время генерации скрипта: 0.1348 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.