Ваше беспокойство правильно. Как правило, пакеты называются либо включением, либо наследование. Я собираюсь составить более реалистичный пример. Допустим, мы строим интернет-магазин.
Включение
Вы первый выбрать пространство имен для вашего проекта.В деловом мире вы часто видите пространства имен с именем компании, чтобы отличать собственные модули от CPAN. Таким образом, пространство имен проекта может быть:
OurCompany::Shop
Тогда, вероятно, основной класс или модуль для приложения называется то же самое, так что мы имеем
OurCompany/Shop.pm
Мы будем иметь кучу вещей, которые нам нужны сделать интернет-магазин. Если наш проект MCV, есть контроллеры и модели и тому подобное. Таким образом, у нас могут быть такие вещи:
OurCompany::Shop::Controller::ProductSearch
OurCompany::Shop::Controller::Cart
OurCompany::Shop::Controller::Checkout
OurCompany::Shop::Model::Database
Все эти карты относятся к модулям.
OurCompany/Shop/Controller/ProductSearch.pm
OurCompany/Shop/Controller/Cart.pm
OurCompany/Shop/Controller/Checkout.pm
OurCompany/Shop/Model/Database.pm
Но нет OurCompany::Controller в качестве базового класса. Это имя - просто пространство имен для сортировки.
Тогда есть некоторые вещи, которые только что существуют, и привыкнете OurCompany :: Shop, как движок сеанса.
OurCompany::Shop::Session
Те, кто выходит на первый уровень после проекта, если они не очень специфичны.
Теперь, конечно, есть какой-то двигатель за сеансовой системой. Предположим, мы очень рады и используем Redis для наших сеансов. Если мы реализуем связь самого (которые мы бы не потому, что CPAN сделали уже), мы бы придерживаться, что внедрение в
OurCompany::Shop::Session::Engine::Redis
Единственное, что использует этот модуль Ourcompany :: Магазин :: Session под капот. Основное приложение даже не знает, какой движок используется. Возможно, у вас нет Redis на вашей машине разработки, поэтому вы используете простые файлы.
OurCompany::Shop::Session::Engine::File
Оба они есть, они принадлежат :: Session, но они не привыкают какой-либо другой части системы, поэтому мы подать их прочь, где они принадлежат.
Наследование
Мы также имеем продукты . Базовый класс продукта может быть таким.
OurCompany::Shop::Product
И для этого есть файл.
OurCompany/Shop/Product.pm
Просто, что это базовый продукт никогда не будет использоваться непосредственно в магазине, кроме проверки, что некоторые вещи должны иметь :: продукт в своем дереве наследования (это isa чек). Так что это отличается от :: Session, который используется напрямую.
Но, конечно, мы продаем разные вещи, и у них разные свойства. Все они имеют цены, но обувь имеет размеры и жесткие диски имеют емкость. Поэтому мы создаем подклассы.
OurCompany::Shop::Product::Shoe
OurCompany::Shop::Product::HardDrive
И у них есть свои собственные файлы.
OurCompany/Shop/Product/Shoe.pm
OurCompany/Shop/Product/HardDrive.pm
Мы могли бы также проводить различие между механической Жёсткий и SSD, поэтому мы делаем подкласс :: SSD.
OurCompany::Shop::Product::HardDrive::SSD
OurCompany/Shop/Product/HardDrive/SSD.pm
Так в основном вещи ставятся в том же пространстве имен, если они принадлежат друг другу. Вот древовидное представление нашей библиотеки.
.
└── OurCompany
├── Shop
│ ├── Controller
│ │ ├── Cart.pm
│ │ ├── Checkout.pm
│ │ └── ProductSearch.pm
│ ├── Model
│ │ └── Database.pm
│ ├── Product
│ │ ├── HardDrive
│ │ │ └── SSD.pm
│ │ ├── HardDrive.pm
│ │ └── Shoe.pm
| ├── Product.pm
│ └── Session.pm
│ │ └── Engine.pm
│ │ ├── File.pm
│ │ └── Redis.pm
└── Shop.pm
Подводя итог:
- Для вашего основного модуля, имя файла является последней частью имени пакета проекта. Все остальное идет под ним.
- Материал, который принадлежит вместе, группируется под одним пространством имен.
- Материал, который наследуется от чего-то, находится под этим пространством имен.
- Материал, который используется только одной конкретной вещи, относится к этой вещи.
Никогда не добавляйте вещи вместе, как MyProject :: AB, чтобы указать, что они принадлежат MyProject :: A. Всегда используйте разделители пространства имен для организации пространств имен. Рассмотрим это, который выглядит просто неправильно:
OurCompany::ShopProductShoe
1) Может быть, у нас также есть приложение BackOffice, который также использует одни и те же классы продуктов. В этом случае мы можем использовать их как OurCompany :: Product, и они будут использоваться двумя разными проектами: OurCompany :: Shop и OurCompany :: BackOffice.
Действительно. Позвольте мне изменить свой вопрос с фактическими классами. –
Под _композицией вы подразумеваете, что он использует объекты этих классов? – simbabque
Извините за неправильный пример. В основном, он содержит хэши объектов из этих классов. –