Лось ООП или Стандартный Perl?

Question

Я собираюсь написать несколько сканеров для веб-сайта, идея в том, что сайт будет использовать некоторые фоновые Perl-скрипты для извлечения данных с других сайтов, мой дизайн (очень абстрактно ...) чтобы написать пакет, скажем:

package MyApp::Crawler::SiteName

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

В любом случае, говоря коротко, мой вопрос: почему (или почему бы и нет ...) мне лучше предпочесть Moose стандартному OO Perl?

Спасибо

Answer 1

Хотя я не согласен с введением Флимзи («Я не использовал Moose, но я использовал эту вещь, которая использует Moose»), я согласен с его посылкой.

Используйте то, что, по вашему мнению, вы можете достичь наилучших результатов.Если (или а) цель состоит в том, чтобы научиться эффективно использовать Moose, то используйте Moose .Если цель состоит в том, чтобы создать хороший код, и изучение Moose будет отвлечением от этого , то не используйте Moose.

Ваш вопрос, однако, является открытым(как уже отмечали другие).Нет никакого ответа, который будет общепринятым как верный, иначе уровень усыновления Лося был бы намного выше, и я не буду отвечать на это.Я могу только объяснить, почему я выбираю Moose каждый раз, когда начинаю новый проект.

Как цитирует Сид из документации по Moose.Основная цель Moose - быть более чистым, стандартизированным способом выполнения того, чем занимались программисты объектно-ориентированного Perl с момента выпуска Perl 5.0.Он предоставляет ярлыки, которые упрощают правильные действия, а не неправильные.Что-то, чего, на мой взгляд, не хватает в стандартном Perl.Он предоставляет новые инструменты, которые упрощают абстрагирование вашей проблемы в более мелкие и легко решаемые проблемы, и предоставляет надежный API для самоанализа и метапрограммирования, который пытается нормализовать beastiary, который взламывает внутренние компоненты Perl из пространства Perl (то есть то, на что я ссылалсякак таблица символов Witchery).

Я обнаружил, что мое естественное представление о том, сколько кода «слишком много», уменьшилось на 66% с тех пор, как я начал использовать Moose [^ 1].Я обнаружил, что мне легче следовать хорошим принципам проектирования, таким как инкапсуляция и сокрытие информации, поскольку Moose предоставляет инструменты, которые облегчают его, а не делают.Поскольку Moose автоматически генерирует большую часть базовой схемы, которую я обычно должен был бы выписывать (например, методы доступа, методы делегирования и другие подобные вещи), я считаю, что легче быстро освоиться с тем, что я делал шесть месяцевтому назад.Я также нахожу, что пишу куда менее хитрый код, чтобы сэкономить несколько нажатий клавиш, чем несколько лет назад.

Можно написать чистый, надежный и элегантный объектно-ориентированный Perl, который не использует Moose[^ 2].По моему опыту, это требует больше усилий и самоконтроля.Я обнаружил, что в тех случаях, когда проект требует, чтобы я не мог использовать Moose, мой обычный объектно-ориентированный код извлекал выгоду из привычек, которые я приобрел у Moose.Я думаю об этом так же, как и о написании его с помощью Moose, а затем набираю в три раза больше кода, чем записываю то, что, как я ожидаю, Moose сгенерирует для меня [^ 3].

Поэтому я использую Mooseпотому что я считаю, что это делает меня лучшим программистом, и из-за этого я пишу лучшие программы.Если вы не находите, что это верно и для вас, то Moose - неправильный ответ.

[^ 1]: Я начинал думать о своем дизайне, когда достигал ~ 300 строккод в модуле.Теперь я начинаю беспокоиться о ~ 100 строк.

[^ 2]: код Миягавы в Twiggy - отличный пример, который я читал только сегодня.

[^ 3]: Это не всегда так.Существует несколько историй о людях, которые пишут менее обслуживаемый, ужасающий код, не обращая внимания на инструменты, предоставляемые Moose.Плохие программисты могут написать плохой код где угодно.

Answer 2

Вы найдете ответ, почему использовать Moose в документации к нему.

Основная цель Moose - сделать объектно-ориентированное программирование на Perl 5 более простым, последовательным и менее утомительным. С Moose вы можете больше думать о том, что вы хотите делать, и меньше о механике ООП.

Из моего опыта и, вероятно, другие скажут вам то же самое. Moose очень сильно уменьшает размер кода, у него много функций, и только стандартные функции, такие как проверка, принудительные значения при создании объекта, отложенная проверка, значения по умолчанию и т. Д., Настолько просты и читаемы, что вы никогда не захотите пропустить Moose.

Answer 3

Использование Лось . Это из того, что я написал вчера вечером (в этом случае Mouse ). Должно быть совершенно очевидно, что он делает, что он проверяет и что настраивает. Теперь представьте, что вы пишете эквивалентный необработанный OO. Это не супер сложно, но становится все труднее читать, и не только сам код, но и цель, которая может быть самой важной частью при чтении кода, который вы не видели раньше или в течение некоторого времени.

has "io" =>
    is => "ro",
    isa => "FileHandle",
    required => 1,
    handles => [qw( sysread )],
    trigger => sub { binmode +shift->{io}, ":bytes" },
    ;

В прошлом году я написал большой тестовый класс, в котором также использовалась функция handles для повторной отправки тонны методов к базовому объекту Selenium / WWWMech. Исчезновение такого рода шаблонов может действительно помочь читаемости и обслуживанию.

Answer 4

Когда я узнал об объектах в Perl, первым делом я подумал, почему это так сложно, когда Perl обычно пытается упростить задачу.

С Moose я вижу, что несложный ООП возможен в Perl.Это как бы возвращает ООП Perl к управляемому уровню.

(да, я признаю, мне не нравится дизайн объектов perl.)

Answer 5

Я никогда не использовал Moose, но я использовал Catalyst и имею большой опыт работы с OO Perl и не OO Perl. И мой опыт подсказывает мне, что лучший метод - это метод, который вам удобнее всего использовать.

Для меня этот метод стал «чем угодно, кроме Катализатора» :) (Нельзя сказать, что люди, которые любят и ругаются Катализатором, неправы - это только мой вкус).

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

Я думаю, что это просто еще один пример "какой язык лучше?" на который никто не может ответить, кроме как от человека.