Исправление обезьяны По сравнению с принципами S.O.L.I.D.?
8 ответов
Существует различие между исправлением обезьяны (перезапись или изменение предсуществовавших методов) и простым добавлением новых методов. Я думаю, что последний совершенно здоров, и на первого нужно посмотреть подозрительно, но я все еще выступаю за хранение его.
я встретился с довольно многими теми проблемами, где стороннее расширение monkeypatches оперативные библиотеки и вещи повреждений, и они действительно сосут. К сожалению, они все неизменно кажутся основой от сторонние разработчики расширения, берущие путь наименьшего сопротивления, вместо того, чтобы думать о том, как на самом деле создать их решения правильно.
Это сосет, но это больше не отказ исправления обезьяны, чем это - отказ производителей ножей, которых люди иногда сокращают сами.
единственные времена я когда-либо видел, что законная потребность в исправлении обезьяны состоит в том, чтобы работать вокруг ошибок в третьем лице или оперативных библиотеках. Для этого одного, это является бесценным, и я действительно был бы разочарован, если бы они удалили способность сделать это.
Временная шкала ошибки в программе C# мы имели:
- Read странные отчеты об ошибках и проблема трассировки к незначительной ошибке в библиотеке CLR.
- Инвестируют дни, придумывающие ловлю вовлечения обходного решения исключения в странных местах и большом количестве взломов, которое идет на компромисс, код много
- Проводят дни, высвобождая hacky обходное решение, когда Microsoft выпускает пакет обновления
Временная шкала ошибки в программе направляющих, мы имели:
- Read странные отчеты об ошибках и проблема трассировки к незначительной ошибке в рубиновой стандартной библиотеке
- Проводят 15 минут, выполняя незначительный патч обезьяны для удаления ошибки из рубиновой библиотеки и защиты места вокруг этого, чтобы сместиться, если это выполняется на неверной версии рубина.
- Продолжаются с нормальным кодированием.
- Просто удаляют monkeypatch позже, когда следующая версия рубина выпущена.
процесс bugfixing выглядит подобным, кроме с monkeypatching, это - 15-минутное решение и 5-секундное 'извлечение', тогда как без него, боль и страдание следует.
пз: следующий пример "технически" monkeypatching, но является им "нравственно" monkeypatching? Я не изменяю поведения - это более или менее просто делает AOP в рубине...
class SomeClass
alias original_dostuff dostuff
def dostuff
# extra stuff, eg logging, opening a transaction, etc
original_dostuff
end
end
Исправление обезьяны не является рубиново-явным, его сделанный на всем протяжении JavaScript также, с отрицательными эффектами (IMO).
Мое личное мнение является исправлением обезьяны, должен только быть сделан к
, a) Добавляют функциональность к старой версии языка, который доступен в новой версии языка, в котором Вы нуждаетесь.
b), Когда нет никакого другого "логического" места для него.
существуют много много простых способов сделать обезьяну, исправляющую действительно ужасный, такую как способность измениться как основные функции такой как ДОПОЛНЕНИЕ работа.
Моя позиция, если можно избежать его, сделать так.
, Если можно избежать его хорошим способом, благодарностью Вам.
, Если Вы не можете избежать его, получите мнение 200 человек, потому что Вы, вероятно, просто не думали об этом достаточно трудно.
Мой главный объект неприязни является mootools расширение функция объект. Да, можно сделать это. Вместо людей, просто учащихся, как JavaScript работает:
setTimeout(function(){
foo(args);
}, 5000 );
Там был добавлен новый метод к каждому функциональному объекту, (да, я не шучу) так, чтобы функции теперь имели свои собственные функции.
foo.delay( 5000 , args );
, Который имел дополнительный эффект этого вида дерьма, являющегося допустимым:
foo.delay.delay( 500, [ 500, args ] );
И на подобном этот до бесконечности.
результат? У Вас больше нет библиотеки и языка, Ваш язык кланяется библиотеке и если библиотека, оказывается, находится в объеме, у Вас больше нет языка, и Вы наклоняетесь, просто делают вещи способ, которым они были сделаны, когда Вы учите язык, и вместо этого должны учиться новый , подмножество команд только для не имения его не имеет успеха на его поверхности (за счет чрезмерного замедления!)
может я отмечать, что foo.delay также возвратил объект с его собственными методами, таким образом, Вы могли сделать
x = foo.delay( 500, args );
x.clear();
и даже
x.clear.delay(10);
, который может звучать чрезмерно полезным... но необходимо учесть, что крупные издержки раньше делали это жизнеспособным.
clearTimeout(x);
НАСТОЛЬКО ТРУДНО!
(Правовая оговорка: его некоторое время, так как я использовал мычание и попытался забыть его, и функциональные имена/структура, может быть неправильным. Это не ссылка API. Проверьте их сайт на детали (извините, их ссылка API сосет!))
По моему мнению, monkeypatching полезен для имения, но что-то, чем можно злоупотребить. Люди склонны обнаруживать его и чувствовать, что это должно использоваться в каждой ситуации, где, возможно, смешивание или другая конструкция могут быть более соответствующими.
я не думаю, что это - что-то, что необходимо запретить, это - просто что-то, что парням Ruby нравится использовать. Можно сделать подобные вещи с Python, но сообщество заняло позицию, что вещи должны быть более простыми и более очевидными.
Mokeypatching вообще неправ. Создайте надлежащий подкласс и добавьте методы.
я использовал monkeypatching однажды в производственном коде.
проблема - то, что использование REST ПОЛУЧАЕТ, POST, ПОМЕЩАЕТ и УДАЛЯЕТ. Но Django тестирует клиент, только предлагает, ДОБИРАЮТСЯ и POST. Я имею monkeypatched методы для ПОМЕЩЕННОГО (как POST) и УДАЛЯЮ (как, ДОБИРАЮТСЯ).
из-за трудной привязки между клиентом Django и тест-драйвером Django, это казалось самым легким monkeypatch это для поддержки полного тестирования REST.
Можно найти просвещение это обсуждение об открытых классах Ruby и Открыто закрытом Принципе.
Даже при том, что мне нравится Ruby, я чувствую, что исправление обезьяны является инструментом последней инстанции для добиваний цели. При прочих равных условиях я предпочитаю использовать традиционные методы OO с опрыскиванием совершенства функционального программирования.
В моих глазах исправление обезьяны является одной формой AOP. Статья Аспектно-ориентированные Принципы разработки: Уроки от Объектно-ориентированного Дизайна (PDF) дают некоторое представление о том, как ТВЕРДЫЕ и другие принципы ООП могут быть применены к AOP.
Моя первая мысль - то, что исправление обезьяны нарушает OCP, так как клиенты класса должны быть в состоянии ожидать что класс работать последовательно.
Исправление обезьяны просто неправильно , по моему скромному мнению. Я не столкнулся с открываться/закрывать принципом, который Вы упоминаете прежде, но это - принцип, который я долго держал сам, я согласовываю с ним 100%. Я думаю об исправлении обезьяны как о запахе кода в более крупном масштабе, запахе философии кодирования, как это было.