Каков официальный шаблон дизайна «обезьяноподготовки»? - PullRequest
Новая
       12

Каков официальный шаблон дизайна «обезьяноподготовки»?

0 голосов
/ 03 декабря 2009

Основной вопрос CS здесь: шаблонов проектирования, перечисленных в Gamma, и т. Д., Какие (если таковые имеются) охватывают обезьяньей патчинг? Кроме того, для какого класса проблем подходит monkeypatching против подклассов? Исправление ошибок в основных классах библиотеки - это одно, есть ли другие? Я слышал много шума и потрясений по поводу установки обезьян на стеке, большинство из вас, похоже, испытывают серьезные опасения по этому поводу, но как программисту мне действительно нравится возможность инкапсулировать общие функциональные возможности и включать их в мои объектные модели в рельсах.

Возьмем, например, thinkbot-paperclip, зачем мне хотеть когда-либо хотеть создать подкласс, который бы соответствовал подходу monkeypatch, который существует сегодня?

Спасибо, -Эрик

1 Ответ

1 голос
/ 04 декабря 2009

Я не думаю, что monkeypatching - это шаблон проектирования - расширение базового класса - языковая функция, которую они, похоже, игнорируют.

Что касается остальных, взгляните на взгляды Джеффа Этвуда на эту статью в своем блоге .

По его (и моему) мнению, самая большая проблема с monkeypatching состоит в том, что это может сделать отладку очень сложной, если она изменяет существующие методы - мы, люди, не можем отслеживать все "маленькие фрагменты здесь и там", а также машины делают. Подклассы стабильно более четкого разделения.

Итак, мои личные правила для обезьяноподготовки:

  • Если вы можете сделать это без monkeypatching, и он будет работать нормально, не используйте monkeypatching.
  • Вы можете добавлять новые методы в классы, но не можете изменять существующие.
  • Сделайте это очень наглядным и очевидным способом - то есть файл с именем string_extensions.rb в вашем / lib, а не в скрытом /myvendor/submodule/se.rb.
  • Должно быть местным; классы, которые не используют библиотеку, не должны быть затронуты.

Теперь к вашему примеру: Скрепка.

  • Насколько мне известно, он добавляет методы к вашим классам ActiveRecord, но не изменяет существующие
  • Вы должны добавить директиву has_attachment к классам, которые используют скрепку, иначе они не будут затронуты.

Таким образом, изменения локализованы и очевидны (на самом деле, мне кажется, что улучшает отладку: нам, людям, легче читать has_attachment вместо class MyModel < Paperclip::ActiveRecordWithAttachment).

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

А в случае Paperclip это явно has_a отношение с его вложением, а не is_a. Можно утверждать, что это не будет правильным использованием подклассов.

Наконец, я хотел бы отметить, что в некоторых случаях Paperclip требует создания подклассов (вы должны использовать подклассы для создания процессора для скрепок).

...