Pergunta

De acordo com a Wikipedia, um monkey patch é:

uma maneira de estender ou modificar o tempo de execução código de linguagens dinâmicas [...] sem alterar a fonte original código.

A seguinte declaração da mesma entrada me confundiu:

Em Ruby, o patch termo macaco era mal entendido para significar qualquer dinâmico modificação para uma classe e é muitas vezes usado como um sinônimo para dinamicamente modificar qualquer classe em tempo de execução.

Eu gostaria de saber o significado exato de patching macaco em Ruby. Está fazendo algo como o seguinte, ou é outra coisa?

class String
  def foo
    "foo"
  end
end
Foi útil?

Solução

A resposta curta é que não há nenhum significado "exata", porque é um romance prazo, e diferentes pessoas usá-lo de forma diferente. Pelo menos isso pode ser discernido da Wikipedia. Há alguns que insistem que ele só se aplica ao código "runtime" (built-in aulas, suponho), enquanto alguns iria utilizá-lo para se referir à modificação de tempo de execução de qualquer classe.

Pessoalmente, eu prefiro a definição mais inclusiva. Afinal, se tivéssemos que usar o termo para a modificação de built-in apenas as classes, como é que nos referimos a modificação de tempo de execução de todas as outras classes? O importante para mim é que há uma diferença entre o código-fonte e a classe de funcionamento real.

Em Ruby, o patch termo macaco era mal entendido para significar qualquer dinâmico modificação para uma classe e é muitas vezes usado como um sinônimo para dinamicamente modificar qualquer classe em tempo de execução.

A declaração acima afirma que o uso de Ruby é incorreta -. Mas termos evoluir, e que nem sempre é uma coisa ruim

Outras dicas

A melhor explicação que eu ouvi para Monkey patch / Duck-perfurando é por Patrick Ewing em RailsConf 2007

... se ele anda como um pato e fala como um pato, é um pato, certo? assim se este pato não está dando-lhe o ruído que você quer, você tem que apenas perfurar o pato até que ele retorne o que você espera.

Monkey patch é quando você Substitua métodos de uma classe em tempo de execução ( não adicionando novos métodos como outros já descritos).

Além de ser um muito un-óbvio e difícil de depurar maneira de código de mudança, ela não escala; como mais e mais módulos iniciar métodos de aplicação de patches de macacos, a probabilidade das mudanças pisando mutuamente a crescer.

Você está correto; que é quando você modificar ou estender uma classe existente em vez de subclasse-lo.

Esta é macaco patching:

class Float
  def self.times(&block)
    self.to_i.times { |i| yield(i) }
    remainder = self - self.to_i
    yield(remainder) if remainder > 0.0
  end
end

Agora eu imagino que pode ser às vezes úteis, mas imagine se você viu rotina.

def my_method(my_special_number)
  sum = 0
  my_special_number.times { |num| sum << some_val ** num }
  sum
end

e quebra única ocasionalmente quando é chamado. Para aqueles prestando atenção você já sabe por que, mas imagine que você não sabia sobre o tipo float ter uma classe método .times e você assume automaticamente que my_special_number é um inteiro. Toda vez que o parâmetro for um número inteiro, inteiro ou float, que iria funcionar bem (ints inteiras são passados ??para trás, exceto quando há um resto de ponto flutuante). Mas passar um número com qualquer coisa na área de decimal e ele vai quebrar com certeza!

Basta imaginar quantas vezes isso pode acontecer com suas jóias, Rails plugins, e até mesmo por seus próprios colegas de trabalho em seus projetos. Se há um ou dois métodos pouco lá como este e que pode demorar algum tempo para encontrar e corrigir.


Se você quer saber porque ele quebra, nota que sum é um inteiro e um resto de ponto flutuante poderia ser passado para trás; Além disso, o sinal exponencial só funciona quando os tipos são os mesmos. Então você pode pensar que é fixo, porque você convertido incomoda números para carros alegóricos ... apenas para descobrir que a soma não pode tomar o resultado de ponto flutuante.

Em Python monkeypatching é referido um monte como um sinal de constrangimento: "Eu tive que monkeypatch esta classe porque ..." (I encontrou pela primeira vez quando se lida com Zope, que o artigo menciona). É usado para dizer que era necessário para tomar posse de uma classe a montante e corrigi-lo em tempo de execução em vez de fazer lobby para que os comportamentos indesejados fixos na classe real ou corrigi-los em uma subclasse. Na minha experiência de Ruby pessoas não falam sobre monkeypatching que muito, porque não é considerado especialmente ruim ou até mesmo digno de nota (daí o "perfuração pato"). Obviamente você tem que ter cuidado sobre como alterar os valores de retorno de um método que será usado em outras dependências, mas a adição de métodos para uma classe da maneira que active_support e facetas fazer é perfeitamente seguro.

Atualização de 10 anos mais tarde : Eu iria alterar a última frase para dizer "é relativamente seguro". Estendendo uma classe biblioteca central com novos métodos podem levar a problemas se alguém recebe a mesma idéia e acrescenta o mesmo método com uma implementação ou método de assinatura diferente, ou se as pessoas confundem métodos estendidos para a funcionalidade núcleo da linguagem. Ambos os casos muitas vezes acontecem em Ruby (especialmente sobre os métodos active_support).

Geralmente se entende sobre as mudanças ad-hoc, usando Ruby aulas abertas, muitas vezes com o código de baixa qualidade.

Boa follow-up sobre o assunto:

http://www.infoq.com/articles/ruby-open -aulas-monkeypatching

Explicação do conceito sem código:

A discussão sobre o conceito exato é waaaay demasiado académico e matizada do que precisa ser. Vamos mantê-lo simples com o seguinte exemplo:

A operação normal de um carro

Como você normalmente começam um carro? É simples: você ligar a ignição, o carro começa, e pronto você está pronto para as corridas

Monkey Patching um carro

Mas e se alguém fez o carro eo que se você quiser mudar a forma como ele funciona?

Você não precisa ir para o carro fábrica da fabricação para fazer essas alterações: você pode simplesmente “macaco-patch” que, por ficar sob o capô e surreptiously e sneakily religação coisas e adicionando algumas incideniaries aqui e ali. Você realmente tem que saber o que você está fazendo quando você fazer isso de outra forma os resultados poderiam ser bastante explosiva - e talvez isso é exatamente o que você quer?

Fabrizzio, onde você está indo?

Crescimento!

 segunda-feira, terça-feira, qua-nes-dia, quinta-feira, sexta-feira, Sat-a-dia imagem é livre e open source de unsplash - https://unsplash.com/photos/dyrehVIidQk

"Mantenha o seu código fonte próxima, mas suas macaco manchas mais perto."

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top