Qual é o padrão formal de design por trás do “Monkeypatching”?

Question

PERGUNTA DA CS CEUS aqui: dos padrões de design listados em gama, etc, que (se houver) cobrem o Monkeypatching? Além disso, para que classe de problemas é o Monkeypatching apropriado versus a subclasse? Patching bugs nas aulas de biblioteca principal é uma, existem outros? Eu ouço muito Sturm und Drang sobre o Monkeypatching no Stackoverflow, a maioria de vocês parece ter receios fortes, mas como programador eu realmente gosto da capacidade de encapsular pedaços genéricos de funcionalidade e incluí -los nos meus modelos de objetos em trilhos.

Veja o pensamento-paperclip, por exemplo, por que eu gostaria de subclasse que vs a abordagem do Monkeypatch que existe hoje?

Obrigado, -eric

Answer 1

Eu não acho que o Monkeypatching seja um padrão de design - Extensão da classe Core Um recurso de linguagem que eles parecem ignorar.

Em relação ao resto, dê uma olhada nas opiniões de Jeff Atwood sobre Este artigo em seu blog.

Em seu (e meu) opção, o maior problema com o Monkeypatching é que ele pode dificultar a depuração, se modificar os métodos existentes - nós, humanos, não conseguimos acompanhar todos os "pequenos trechos aqui e ali", assim como as máquinas. Subclasses separações mais claras.

Portanto, minhas regras pessoais para o Monkeypatching são:

• Se você puder fazer isso sem o Monkeypatching e funcionará bem, não use o Monkeypatching.
• Você pode adicionar novos métodos às classes, mas não pode modificar as existentes.
• Faça isso de uma maneira muito visível e óbvia - ou seja, um arquivo chamado string_extensions.rb no seu /lib, não em um /myvendor oculto/submodule/se.rb.
• Deve ser local; As classes que não usam uma biblioteca devem não ser afetadas.

Agora, para o seu exemplo: PaperClip.

• Que eu saiba, ele adiciona métodos às suas classes ActiveRecord, mas não modifica as existentes
• Você tem que adicionar um has_attachment Diretiva para as classes que usam o PaperClip, caso contrário, elas não serão afetadas.

Portanto, as mudanças são localizadas e óbvias (eu realmente acho que isso consegue melhorar Depuração: é mais fácil para nós, humanos, ler has_attachment ao invés de class MyModel < Paperclip::ActiveRecordWithAttachment).

A subclasse também é uma má idéia nesse caso, porque você não seria capaz de usar o PaperClip, além de outro plug -in que usava subclasses - os trilhos são exclusivos.

E no caso de PaperClip, é claramente um has_a relacionamento com seu apego, não um is_a 1. Pode -se argumentar que não seria um uso adequado da subclasse.

Por fim, gostaria de ressaltar que o PaperClip requer subclasse em algumas ocasiões (você deve usar a subclasse para criar um processador de papel).