Wenn Sie eine Methode mit Affen patchen, können Sie die überschriebene Methode von der neuen Implementierung aufrufen?

BEARBEITEN: Es hat schon 5 Jahre her, seit ich ursprünglich schrieb diese Antwort, und er verdient einige kosmetische Chirurgie zu halten, aktuell.

Können Sie sehen die Letzte version vor dem edit -hier.

---

Können Sie nicht, rufen Sie die überschrieben Methode von Namen oder Schlüsselwörtern. Das ist einer der vielen Gründe, warum monkey-patching sollten vermieden werden und der Vererbung bevorzugt werden, statt, da Sie natürlich kann rufen Sie die überschrieben Methode.

Vermeidung Von Monkey-Patching

Vererbung

Also, wenn überhaupt möglich, sollten Sie lieber so etwas wie dieses:

class Foo
  def bar
    'Hello'
  end
end 

class ExtendedFoo < Foo
  def bar
    super + ' World'
  end
end

ExtendedFoo.new.bar # => 'Hello World'

Dies funktioniert, wenn Sie die Kontrolle Erstellung der Foo Objekte. Ändern Sie einfach jeden Ort, der schafft eine Foo zu erstellen Sie stattdessen eine ExtendedFoo. Das funktioniert noch besser, wenn Sie die Dependency Injection Design Patterndie Factory Method Design Patterndie Abstract Factory Design Pattern oder etwas entlang jenen Linien, da in diesem Fall, es ist der einzige Ort, den Sie brauchen, um zu ändern.

Delegation

Wenn Sie nicht Erstellung der Foo Objekte, zum Beispiel, weil Sie geschaffen sind, durch einen Rahmen, der außerhalb Ihrer Kontrolle (wie ruby-on-rails zum Beispiel), dann könnten Sie den Wrapper Design Pattern:

require 'delegate'

class Foo
  def bar
    'Hello'
  end
end 

class WrappedFoo < DelegateClass(Foo)
  def initialize(wrapped_foo)
    super
  end

  def bar
    super + ' World'
  end
end

foo = Foo.new # this is not actually in your code, it comes from somewhere else

wrapped_foo = WrappedFoo.new(foo) # this is under your control

wrapped_foo.bar # => 'Hello World'

Grundsätzlich an der Grenze des Systems, wo die Foo Objekt kommt in den code, wickeln Sie es in ein anderes Objekt, und verwenden Sie dann dass Objekt statt der ursprünglichen überall in Ihrem code.

Diese nutzt die - Objekt#DelegateClass Helfer-Methode aus der delegieren Bibliothek in der stdlib.

"Sauber" Monkey-Patching

Module#prepend: Mixin Voranstellen

Den beiden oben genannten Methoden erfordern eine änderung des Systems zu vermeiden, monkey-patching. Dieser Abschnitt zeigt die bevorzugte und am wenigsten invasive Methode der monkey-patching, sollte das system wechseln und nicht eine option sein.

Module#prepend wurde Hinzugefügt, um Unterstützung mehr oder weniger genau diesen Anwendungsfall. Module#prepend macht das gleiche wie Module#includeaußer es mischt sich in die mixin direkt unten der Klasse:

class Foo
  def bar
    'Hello'
  end
end 

module FooExtensions
  def bar
    super + ' World'
  end
end

class Foo
  prepend FooExtensions
end

Foo.new.bar # => 'Hello World'

Hinweis: ich schrieb auch ein wenig über Module#prepend in dieser Frage: Ruby-Modul voranstellen vs Ableitung

Mixin-Vererbung (kaputt)

Ich habe gesehen, einige Leute versuchen (und Fragen Sie, warum es hier nicht funktioniert auf StackOverflow) so etwas wie dieses, D. H. includeing ein mixin statt prepending:

class Foo
  def bar
    'Hello'
  end
end 

module FooExtensions
  def bar
    super + ' World'
  end
end

class Foo
  include FooExtensions
end

Leider, das wird nicht funktionieren. Es ist eine gute Idee, denn es nutzt Vererbung, was bedeutet, dass Sie verwenden können super. Allerdings - Modul#include fügt Mixins oben die Klasse in der Vererbungshierarchie, was bedeutet, dass FooExtensions#bar wird nie aufgerufen werden (und wenn es wurden genannt, die super würde nicht wirklich finden Foo#bar sondern Object#bar welche nicht vorhanden ist), da Foo#bar wird immer gefunden werden, ersten.

Methode Verpackung

Die große Frage ist: wie können wir halten, um die bar Methode, ohne tatsächlich halten, um eine eigentliche Methode? Die Antwort liegt, wie so oft, in die funktionale Programmierung. Wir fassen die Methode als eine tatsächliche Objektund wir verwenden einen Verschluss (z.B. ein block), um sicherzustellen, dass wir und nur wir halten, um das Objekt:

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  old_bar = instance_method(:bar)

  define_method(:bar) do
    old_bar.bind(self).() + ' World'
  end
end

Foo.new.bar # => 'Hello World'

Dieser ist sehr sauber: da old_bar ist nur eine lokale variable geht out of scope am Ende der Klasse Körper, und es ist unmöglich, es von überall aus zugreifen, auch mit der spiegelung! Und da Modul#define_method nimmt einen block, und Blöcke in der Nähe über die Sie umgebenden lexikalischen Umgebung (das ist warum wir sind mit define_method statt def hier), es (und nur es) wird immer noch Zugriff auf old_barauch nachdem er gegangen ist out of scope.

Kurze Erklärung:

old_bar = instance_method(:bar)

Hier sind wir die Verpackung des bar Methode in eine UnboundMethod Methode-Objekts und Zuweisung an die lokale variable old_bar. Das heißt, wir haben jetzt einen Weg zu halten, um bar auch wenn es überschrieben wurde.

old_bar.bind(self)

Dies ist ein bisschen schwierig. Im Grunde, in Ruby (und in so ziemlich alle single-dispatch-basierte OO-Sprachen), eine Methode, die gebunden ist an einen bestimmten Empfänger-Objekt, genannt self in Ruby. In anderen Worten: eine Methode, die immer weiß, von welchem Objekt es aufgerufen wurde, es weiß, was seine self ist. Aber, wir schnappten uns die Methode, direkt aus einer Klasse, wie weiß er, was seine self ist?

Gut, tut es nicht, das ist, warum wir brauchen, um bind unsere UnboundMethod auf ein Objekt zunächst, die Rückkehr einer Methode Objekt, das wir dann aufrufen kann. (UnboundMethods kann nicht aufgerufen werden, weil Sie nicht wissen, was zu tun ist, ohne zu wissen, Ihre self.)

Und was tun wir bind? Wir haben einfach bind es uns selbst, so wird es sich Verhalten genau wie das original bar hätte!

Schließlich müssen wir die zu nennen, die Method zurückgegeben wird, die von bind. In Ruby 1.9, es gibt einige nette neue syntax (.()), aber wenn Sie sind auf 1,8, können Sie einfach die call Methode; das ist es, was .() übersetzt wird, sowieso.

Hier sind ein paar andere Fragen, wo einige dieser Begriffe werden erläutert:

• Wie kann ich die Verweis-Funktion in Ruby?
• Ist Ruby-code-block dasselbe wie C♯'s lambda-Ausdruck?

"Dirty" Monkey-Patching

alias_method Kette

Das problem, das wir haben mit unserem monkey-patching ist, dass, wenn wir überschreiben die Methode, die Methode ist verschwunden, so dass wir es nicht nennen mehr. Also, lasst uns einfach eine backup-Kopie!

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  alias_method :old_bar, :bar

  def bar
    old_bar + ' World'
  end
end

Foo.new.bar # => 'Hello World'
Foo.new.old_bar # => 'Hello'

Das problem mit diesem ist, dass wir jetzt haben verunreinigt den namespace mit einem überflüssigen old_bar Methode. Diese Methode wird in unserer Dokumentation haben, wird es zeigen sich in der code-Vervollständigung in unserem IDEs, wird es zeigen sich während der Reflexion. Auch, es kann immer noch genannt werden, aber vermutlich werden wir monkey gepatcht, weil wir nicht wie sein Verhalten in den ersten Platz, so dass wir vielleicht nicht wollen, dass andere Menschen es nennen.

Trotz der Tatsache, dass dies hat einige unerwünschte Eigenschaften, es hat leider popularisiert durch AciveSupport ist Modul#alias_method_chain.

Nebenbei: Verfeinerungen

Im Fall brauchen Sie nur das unterschiedliche Verhalten in ein paar bestimmten stellen und nicht im gesamten system, die Sie verwenden können, Verfeinerungen zu beschränken, die monkey patch auf einen bestimmten Gültigkeitsbereich. Ich werde zeigen, dass er hier mit der Module#prepend Beispiel von oben:

class Foo
  def bar
    'Hello'
  end
end 

module ExtendedFoo
  module FooExtensions
    def bar
      super + ' World'
    end
  end

  refine Foo do
    prepend FooExtensions
  end
end

Foo.new.bar # => 'Hello'
# We haven’t activated our Refinement yet!

using ExtendedFoo
# Activate our Refinement

Foo.new.bar # => 'Hello World'
# There it is!

Können Sie sehen, eine anspruchsvolle Beispiel für die Verwendung von Verfeinerungen in dieser Frage: Aktivieren der monkey-patch für bestimmte Methode?

---

Aufgegeben Ideen

Bevor die Ruby-community ließ sich auf Module#prepend gab es mehrere verschiedene Ideen im Umlauf, die Sie gelegentlich sehen, auf die in älteren Diskussionen. Alle diese sind zusammengefasst durch Module#prepend.

Methode Combinators

Einer Idee wurde die Idee der Methode combinators von CLOS. Dies ist im Grunde eine sehr einfache version einer Teilmenge der Aspekt-Orientierten Programmierung.

Verwenden Sie eine syntax wie die

class Foo
  def bar:before
    # will always run before bar, when bar is called
  end

  def bar:after
    # will always run after bar, when bar is called
    # may or may not be able to access and/or change bar’s return value
  end
end

würden Sie in der Lage sein zu "hook" die Ausführung der bar Methode.

Es ist allerdings nicht ganz klar, ob und wie bekommen Sie Zugang zu bar's return-Wert innerhalb bar:after. Vielleicht könnten wir (ab -) Nutzung der super keyword?

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  def bar:after
    super + ' World'
  end
end

Ersatz

Die vor combinator ist äquivalent zu prepending ein mixin mit einer übergeordneten Methode aufruft super ganz Ende der Methode. Ebenso die nach dem combinator ist äquivalent zu prepending ein mixin mit einer übergeordneten Methode aufruft super ganz Anfang der Methode.

Können Sie auch Dinge zu tun, bevor und nach dem Aufruf super sind, können Sie anrufen super mehrere Male, und sowohl das abrufen und Bearbeiten von super's return-Wert, so dass prepend mächtiger als Methode combinators.

class Foo
  def bar:before
    # will always run before bar, when bar is called
  end
end

# is the same as

module BarBefore
  def bar
    # will always run before bar, when bar is called
    super
  end
end

class Foo
  prepend BarBefore
end

und

class Foo
  def bar:after
    # will always run after bar, when bar is called
    # may or may not be able to access and/or change bar’s return value
  end
end

# is the same as

class BarAfter
  def bar
    original_return_value = super
    # will always run after bar, when bar is called
    # has access to and can change bar’s return value
  end
end

class Foo
  prepend BarAfter
end

old Stichwort

Diese Idee fügt ein neues Stichwort-ähnlich superdie können Sie aufrufen, die überschrieben Methode die gleiche Weise super können Sie rufen Sie die überschrieben Methode:

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  def bar
    old + ' World'
  end
end

Foo.new.bar # => 'Hello World'

Das größte problem mit diesem ist, dass es rückwärts ist nicht kompatibel: wenn Sie Methode namens old Sie nicht mehr in der Lage sein, es zu nennen!

Ersatz

super in eine überschreibende Methode in einer prepended mixin ist im wesentlichen der gleiche wie old in diesem Vorschlag.

redef Stichwort

Ähnlich wie oben, aber anstatt das hinzufügen eines neuen Schlüsselwort für aufrufen die überschriebene Methode und verlassen def allein, wir fügen Sie ein neues Schlüsselwort für Neudefinition Methoden. Das ist abwärtskompatibel, da die syntax ist derzeit sowieso illegal:

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  redef bar
    old + ' World'
  end
end

Foo.new.bar # => 'Hello World'

Anstatt zwei neue keywords, könnten wir auch neu definieren, die Bedeutung von super innen redef:

class Foo
  def bar
    'Hello'
  end
end 

class Foo
  redef bar
    super + ' World'
  end
end

Foo.new.bar # => 'Hello World'

Ersatz

redefining eine Methode ist äquivalent zum überschreiben der Methode in einem prepended mixin. super in der übergeordneten Methode verhält sich wie die super oder old in diesem Vorschlag.

InformationsquelleAutor der Antwort Jörg W Mittag

Die Klasse, die machen überschreiben muss neu geladen werden nach der Klasse, die enthält die ursprüngliche Methode, so require es in der Datei, wird overrride.

InformationsquelleAutor der Antwort rplaurindo