|
Модераторы: LSD |
|
JDmitry |
|
|||
Новичок Профиль Группа: Участник Сообщений: 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 этого не содержит) И как вы разделяете свой проект? |
|||
|
||||
LSD |
|
|||
Leprechaun Software Developer Профиль Группа: Модератор Сообщений: 15708 Регистрация: 24.3.2004 Репутация: 1 Всего: 537 |
Здравый смысл Пакеты нужны людям, не Java. Я руководствуюсь соображем что человек посмотрев на структуре пакетов понял где искать классы ответвенные за некий функционал. С этой точки зрения пакет x.x.enums лишен смысла чуть более чем полностью, если руководствоваться подобной логикой то и интерфейсы надо в x.x.interfaces А вообще посмотри на 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. |
|||
|
||||
vanarchi |
|
|||
Новичок Профиль Группа: Участник Сообщений: 1 Регистрация: 16.8.2013 Репутация: нет Всего: нет |
Просматривал недавно из Clean Code Роберта Мартина серию Episode 7 Architecture, Use Cases, and High Level Design.
Там он советует, чтобы структура проекта (в том числе и пакеты) отражала архитектуру. Архитетура это то, что отражает не то как программа сделана (механизмы), а её назначение. Структура
классифицирует как раз механизмы, а не назначение различных подсистем. Приемущества классификации механизмом в том, что они конкретны, конечны и их можно легко классифицировать и даже стандартизировать. Недостатки такой классификции:
- разбить системы на модули (границы или 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 |
|||
|
||||
EvilsInterrupt |
|
|||
Executables research Профиль Группа: Завсегдатай Сообщений: 1019 Регистрация: 14.7.2007 Где: Железнодорожный, МО, Россия Репутация: нет Всего: 9 |
В этой книге дан совет располагать не "по назначению", а согласно "где программист(он или его коллега) будет искать". Другими словами, если в проекте по механизмам, то и надо раскладывать по механизмам. Иначе: Идеальной структуры нету! Все зависит от ситуации, проекта, coding-style и многих прочих других факторов. Совет: Когда Вы ощутите себя нашедшим класс и с мыслью в голове "Никогда бы не подумал, что он тут", то спросите себя "А где то самое первое место откуда я начал поиск?", ну или "какое второе место, куда я посмотрел?". Кладите Ваши вещи туда, где Вы их начинали искать, вполне возможно что и в след. раз Вы тоже начнете искать с тех мест! ;) Однако прежде чем положить в новое место спросите себя: "А почему начал поиск именно от туда?". Также помогают вопросы к коллегам: "Где бы ты стал искать класс.... ?" |
|||
|
||||
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
0 Пользователей: | |
« Предыдущая тема | Java: Design, Quality, Testing | Следующая тема » |
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |