Perl/Moose OO, иерархия пакетов - программирование

Perl/Moose OO, иерархия пакетов

Я средний программист perl. У меня нет проблем с самим языком, но с дизайном объекта хороший. Хотя я могу понять (большинство) модулей CPAN, без серьезных проблем, я не могу создать себе даже простую иерархию объектов.

Пример - теперь перед действительно простым приложением (веб-интерфейс и интерфейс командной строки):

  • уже прошедший аутентификацию студент загружает zip файл (что содержит задание рендеринга)
  • разархивируйте файл и новый каталог и проверьте его содержимое (должно содержать только один файл commands.txt) и ноль или более изображений
  • если содержимое в порядке - переместите каталог на место: JobRepository (другой каталог)
  • если пользователь решил запустить задание рендеринга - отправьте задание из его собственной JobRepository в глобальную очередь рендеринга (опять-таки другой каталог)
  • другой процесс выполняет задания из очереди (fifo - разработан с IPC:: DirQueue) и выполняет процесс рендеринга
  • По завершении введите результат в каталог JobRepository/result
  • отправить электронное письмо пользователю
  • ученик может загрузить заархивированные результаты

В bash это выполнимо с несколькими "не сложными" bash script - но я хочу сделать это в Perl (потому что веб-интерфейс) - и вы хотите, чтобы дизайн объекта perlish (Moose)...

И здесь начинаются мои проблемы.

Попробовал "визуальный" подход существительного-анализа и сделал следующее изображение.

enter image description here

Отправлено изображение, потому что оно "короче":

package Iren::JobRepo;
use Moose;
use warnings;
has 'Jobs' => (is => 'rw', isa=>ArrayRef[Iren::Job]);
…
method AddJob {
...
}

и др.

Как вы можете видеть, это действительно просто - но сразу же сталкиваются с некоторыми проблемами решения, например:

  • Какой объект должен выполнять методы unzip/zip/checkJob? Он принадлежит: JobRepository от самого "Рабочего места"?
  • какой объект должен отправлять электронные письма пользователю? $user->send_email - приходит мне глупо, потому что мы отправляем email пользователям, а не пользователю самому себе...
  • "кто" должен отправить задание от пользователя JobRepo в RenderQueue? JobRepo->SendJobToRenderQueue или я должен вызвать некоторый метод RenderQueue->addJob?
  • какой объект должен использовать ISA IPC::DirQueue - (должно быть реализовано RenderQueue)
  • круговые определения. У пользователя есть JobRepository, в хранилище есть много заданий, но в Job есть? пользователь? (нужно знать, кому принадлежит работа) - и т.д.

Как вы можете видеть, никаких ролей, нет черт здесь - ничего - просто... - но полных вопросов: (

Может кто-нибудь помочь очистить беспорядок? Какая должна быть "хорошая" иерархия пакетов?

Итак, я действительно потерялся, и я начал разочаровываться. Дополнительные вопросы (я знаю, эти мнения основаны) - но я должен их спросить...

  • Как узнать хороший дизайн объекта для perl/Moose? (Я, вероятно, никогда не буду использовать другой язык)
  • поиск google о дизайне объекта (и Stackoverflow тоже) многократно цитируется в книге "Ганд четырех" (и несколько других). Но обычно для Java. Стоит купить для perl/Moose? Или здесь есть еще несколько хороших книг для perl/Moose?
  • - хорошая методика проверки правильного дизайна объекта.
  • Генераторы кода из UML, вероятно, не существуют для Moose - или здесь что-то полезное и исправленное?
  • просто - как вы овладеваете своей иерархией объектов/Роли/Черты и т.д....? Пока я читаю примеры - я понимаю $cat->diets:) - но освоение чего-то нового - плохо для меня...

Извините за стену текста. Я был бы очень счастлив получить любой указатель на хорошую книгу или что-нибудь, что поможет...

4b9b3361

Ответ 1

Материал @daxim не ответил:

  • Как узнать хороший дизайн объекта для perl/Moose? (Я, вероятно, никогда не буду использовать другой язык)
  • Сначала изучите общий дизайн OO (вы, кажется, хорошо разбираетесь в основах)
  • Затем узнайте о ролях. Они помогают упростить ваш дизайн во многих случаях и не являются частью Java OO, которые обычно не рассматриваются в основной литературе OO.
  • Для Perl конкретных вещей, я бы очень рекомендовал Cromatic "Современный Perl" книги, а также полное содержание его Modern Perl блог. Книга можно купить, но IIRC также доступен бесплатно.
  • Кроме того, чтобы узнать, где вам не нужно использовать OO, но с другой силой Perl, настоятельно рекомендуем читать свободную книгу Perl более высокого порядка.
  • Удостоверьтесь, что для практического кодирования, который вы понимаете в дизайне высокого уровня, вы смотрите на Moose (Moo) вместо Perl 5 native OO. Google для "презентаций для лосей" для начинающих.
  • поиск google о дизайне объекта (и Stackoverflow тоже) многократно цитируется в книге "Ганд четырех" (и несколько других). Но обычно для Java. Стоит купить для perl/Moose? Или здесь есть еще несколько хороших книг для perl/Moose?
  • - хорошая методика проверки правильного дизайна объекта.

Честно говоря, лучший способ проверить: (1) Обзор дизайна со второй парой глаз и (2) посмотреть, как ваше удержание держится за обслуживание и повторное использование. Хороший дизайн НЕ должен сильно меняться при каждом обновлении. Я не знаю конкретных технических/процедурных способов проверки.

Хорошее эмпирическое правило: если вам нужно изменить то, как что-то ведет, возможно, радикально, сколько вашего кода нужно будет изменить? Лучший дизайн - это тот, который минимизирует изменения.

  • просто - как вы овладеваете своей иерархией объектов/Роли/Черты и т.д....? Пока я читаю примеры - я понимаю диеты $cat- > :), но освоение чего-то нового - плохо для меня...

Практика. В идеале найти проблему, решаемую учебником/книгой, сначала решить ее, а затем посмотреть, как они ее разрешают. Затем опубликуйте свое лучшее комбинированное решение codereview.SE и спросите, можно ли его улучшить:)


круговые определения. У пользователя есть JobRepository, The Repository имеет много Рабочих мест, но Job имеет? Пользователь? (нужно знать, кому принадлежит задание) - и т.д.

Нет, вам НЕ нужно знать, кому принадлежит эта работа. Я объяснил, почему пару недель назад - ОЧЕНЬ аналогичный вопрос был задан и ответил мной здесь: OO Design Patterns с Perl.

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

Ответ 2

какой объект должен использовать методы unzip/zip/checkJob?

JobRepository

какой объект должен отправлять электронные письма пользователю?

RenderQueue

Мне нужно вызвать некоторый метод RenderQueue- > addJob?

Да, сделайте это так. Ответственность относится к RenderQueue, потому что она сама может решить, принимать ли работу или нет.

какой объект должен использовать ISA IPC:: DirQueue

Mu. Не наследуйте, просто делегируйте.

Пользователь имеет JobRepository

Это неправильно, удалите его.

но Иов имеет? пользователя?

Правильно.


Для двух последних моментов вашего дизайна это очень помогло бы, если бы вы нарисовали диаграмму ER перед UML.