Was ist das formale Designmuster hinter „MonkeyPatching“?

Question

CORE CS -Frage hier: Von den in Gamma aufgeführten Entwurfsmustern usw., welche (falls überhaupt) MonkeyPatching abdecken? Für welche Klasse von Problemen ist MonkeyPatching außerdem angemessen und Subklassing? Das Patching von Fehler in Kernbibliotheksklassen ist einer, gibt es andere? Ich höre viel Sturm und Drang über MonkeyPatching auf Stackoverflow. Die meisten von Ihnen scheinen starke Bedenken zu haben, aber als Programmierer mag ich die Fähigkeit, generische Funktionen zu verkörpern und sie in meine Objektmodelle in Schienen einzubeziehen.

Take ThanfotBot-PaperClip zum Beispiel, warum sollte ich jemals eine Unterklasse für den heute existierenden MonkeyPatch-Ansatz haben wollen?

Danke, -eric

Answer 1

Ich glaube nicht, dass MonkeyPatching ein Designmuster ist - Kernklassenerweiterung Ein Sprachfunktion, das sie zu ignorieren scheinen.

In Bezug auf den Rest schauen Sie sich Jeff Atwoods Ansichten an. Dieser Artikel in seinem Blog.

In seiner (und meiner) Gegner ist das größte Problem bei der MonkeyPatching, dass es das Debuggen sehr schwierig machen kann, wenn es vorhandene Methoden ändert - wir Menschen können nicht alle "kleinen Ausschnitte hier und da" und Maschinen im Auge behalten. Unterklassen stabilen klarere Trennungen.

Meine persönlichen Regeln für MonkeyPatching sind also:

• Wenn Sie es ohne MonkeyPatching tun können und es in Ordnung funktioniert, verwenden Sie keine MonkeyPatching.
• Sie können Klassen neue Methoden hinzufügen, aber Sie können vorhandene nicht ändern.
• Tun Sie es auf sehr sichtbare und offensichtliche Weise - dh eine Datei namens string_extensions.rb in Ihrem /lib, nicht auf einem versteckten /myvendor/submodule/se.rb.
• Sollte lokal sein; Klassen, die keine Bibliothek verwenden, sollten nicht betroffen sein.

Nun zu Ihrem Beispiel: Paperclip.

• Meines Wissens fügt es Methoden zu Ihren ActivereCord -Klassen hinzu, ändert jedoch nicht vorhandene, die vorhanden sind
• Sie müssen a hinzufügen has_attachment Richtlinie zu den Klassen, die Papierklamme verwenden, sonst sind sie nicht betroffen.

Die Änderungen sind also lokalisiert und offensichtlich (ich denke tatsächlich, dass es es schafft verbessern Debugging: ist für uns Menschen einfacher zu lesen has_attachment Anstatt von class MyModel < Paperclip::ActiveRecordWithAttachment).

Die Unterklasse ist auch eine schlechte Idee in diesem Fall, da Sie zusätzlich zu einem anderen Plugin, das Unterklassen verwendete, nicht in der Lage wären, eine einzelne Inerhordung zu verwenden.

Und in Paperclips Fall ist es eindeutig ein has_a Beziehung mit seiner Bindung, nicht a is_a eines. Man könnte argumentieren, dass es keine ordnungsgemäße Verwendung der Unterklasse wäre.

Schließlich möchte ich darauf hinweisen, dass Paperclip in einigen Gelegenheiten eine Unterklasse erfordert (Sie müssen die Unterklasse verwenden, um einen Papierklammerprozessor zu erstellen).