Quel est le modèle formel derrière "monkeypatching"?

Question

Core CS question ici: des motifs de conception énumérés dans Gamma, etc, qui (le cas échéant) couvrent monkeypatching? En outre, pour quelle classe de problèmes monkeypatching approprié vs sous-classement? Corriger des bogues dans les classes de base de la bibliothèque est une, y en a-t-il d'autres? J'entends beaucoup de sturm und drang à propos de monkeypatching sur stackoverflow, la plupart d'entre vous semblent avoir de fortes craintes à ce sujet, mais en tant que programmeur j'aime vraiment la capacité d'encapsuler des fonctionnalités génériques et de les inclure dans mes modèles d'objets en rails. Prenez par exemple thoughtbot-paperclip, pourquoi voudriez-vous jamais vouloir sous-classer cela par rapport à l'approche monkeypatch qui existe aujourd'hui?

Merci, -Eric

Answer 1

Je ne pense pas monkeypatching est un modèle de conception - extension de classe de base d'une caractéristique de langue qu'ils semblent ignorer.

Pour le reste, jetez un oeil à la vue de Jeff Atwood sur this article on his blog. Dans son (et mon) oppinion le plus gros problème avec le monkeypatching est qu'il peut rendre le débogage très difficile, s'il modifie les méthodes existantes - nous les humains ne pouvons pas garder trace de tous les "petits morceaux ici et là" aussi comme le font les machines. Les sous-classes établissent des séparations plus claires.

donc mes règles personnelles pour monkeypatching sont:

• Si vous pouvez le faire sans monkeypatching et cela fonctionnera bien, ne pas utiliser monkeypatching.
• Vous pouvez ajouter de nouvelles méthodes aux classes, mais vous ne pouvez pas modifier celles existantes. Faites-le d'une manière très visible et évidente - c'est-à-dire un fichier appelé string_extensions.rb dans votre/lib, pas sur un /myvendor /submodule/se.rb caché.
• Devrait être local; les classes qui n'utilisent pas de bibliothèque ne devraient pas être affectées.

Maintenant, à votre exemple: Trombone.

• A ma connaissance, il ajoute des méthodes à vos classes ActiveRecord, mais ne modifie pas les existants
• Vous devez ajouter une directive has_attachment aux classes qui utilisent paperclip, sinon ils ne sont pas affectés.

Ainsi, les changements sont localisés et évidente (je pense en fait qu'il parvient à améliorer mise au point: il est plus facile pour nous les humains à lire has_attachment au lieu de class MyModel < Paperclip::ActiveRecordWithAttachment).

Sous-classement est également une mauvaise idée sur ce cas, car vous ne seriez pas en mesure d'utiliser paperclip, en plus d'un autre plugin qui a utilisé des sous-classes - rails est unique hérité.

Et dans le cas de Paperclip, il s'agit clairement d'une relation has_a avec sa pièce jointe, et non une is_a. On pourrait soutenir que ce ne serait pas un bon usage du sous-classement. Enfin, je tiens à souligner que Paperclip nécessite un sous-classement à certaines occasions (vous devez utiliser le sous-classement pour créer un processeur de trombones).