Структура пакета проекта Android - PullRequest
4 голосов
/ 03 апреля 2011

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

spk.myapp.main. (Все классы, используемые в основном действии) spk.myapp.processor. (Все классы, используемые поставщиком процессора)

... и так далее.Однако аспект, который мне не нравится, заключается в том, что соглашение об именах классов и пакетов может быстро стать несовместимым с другими полностью определенными именами, такими как полномочия провайдера (в этом случае я бы лучше назвал эти spk.myapp.processor чем spk.myapp.processor.processor , как подсказывает путь к пакету класса).

Я провел некоторое исследование, но большинство страниц объясняют исходную структуру каталогов проекта, а не предлагают ее для более крупных проектов.

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

Имеется ли у кого-то хорошая и надежная структура пакета проекта и соглашения об именах для проектов Android?

1 Ответ

5 голосов
/ 03 апреля 2011

В Википедии есть полезные заметки о пакетах Java. Пакеты в основном полезны по двум причинам:

  1. Пакет предоставляет уникальное пространство имен для типов, которые он содержит.
  2. Классы в одном и том же пакете могут получать доступ к элементам доступа к пакету друг друга.

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

Второй момент довольно важен и часто упускается из виду. Доступ к пакетам позволяет делать некоторые умные вещи. Например, у вас может быть класс 'builder', который может создавать и заполнять модели, которые имеют свойства доступа к пакету, без добавления большого количества методов установки или использования открытых свойств. Это может сделать создание объекта действительно простым и интуитивно понятным, в то время как объекты остаются неизменяемыми вне пакета.

Действительно хороший пример этого принципа можно найти в приложении Полки Романа Гая. Класс BookStore может создавать объекты Book и изменять их члены, не предоставляя эти поля другим классам (в других пакетах).

...