> Действительно странного хотите. > По-моему более очевидно для каждой сущности (игрушка, заказ, пользователь) > сделать отдельный класс (не роль), в котором прописать, в какой таблице > хранятся записи для этого класса, а в роль вынести как раз работу с БД.
для каждой сущности (игрушка, заказ, пользователь) уже есть классы но далее есть запросы вида: - а какие игрушки у пользователя? - а какие заказы у пользователя и подобные то есть это как раз то что находится между классами. > Примерно так мы делаем в нашем проекте на работе. При этом никто не мешает > добавить в класс User метод orders(), который будет возвращать список заказов > данного пользователя. именно этой дорогой и шли. но когда появляется несколько видов построения списка orders, то получается что все виды выносим в отдельную роль (или надкласс). а функции начинают получать префиксы и (или) суффиксы list_orders_processing list_orders_done я может суррогатный пример привел, вы на пример смотрите именно как на пример. и вот когда функций в одной роли плодится много, то вот хочется неких неймспейсов чтобы эти функции разделять > Кусок кода, который иллюстрирует вышесказанное, приведен ниже (я в нём > использую более привычный мне Moose, но код на Mouse должен выглядеть похоже, > если не идентично). это все понятно. именно от этого и идем. просто возьмем любой большой проект. в нем всегда есть сущности имеющие отношения на много чего например юзер: - может иметь заказы, игрушки, итп итд - другие сущности. соответственно построение списков, ответы на вопросы чего он имет итп - имеет какие-то привелегии - имеет какие-то отношения с другими пользователями и так далее в большом проекте такой список постоянно растет и вот роли (или надклассы - в зависимости от ситуации) помогают раскидать методы по разным пакетам по крайней мере. но все методы в итоге лежат в одном пакете сколько бы ролей/надклассов мы не сделали. далее возникают коллизии: два разных человека сделали одинаковое имя у какого-то has в разных ветвях иерархии поскольку данные коллизии иногда выявляются сложно (в том числе и тестами), то в итоге в большом проекте вводятся ручные полиси, типа если у нас пакет Package::Name, а имеет роль Package::Thing, то все методы в Package::Thing обязаны иметь префикс thing_ ну а раз так то почему бы не преобразовать thing_ в thing-> и убрать из полиси разработки пункт :) -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
