Was bedeutet _Duckmäusertippen_ in der Softwareentwicklung bedeuten?
Antworten
Zu viele Anzeigen?Seien Sie kein Quacksalber, ich halte Ihnen den Rücken frei:
"Duck typing" := "probiere die Methoden aus, prüfe nicht den Typ"
Anmerkung: <code>:=</code> kann gelesen werden als <em>"ist definiert als" </em>.
" Ente tippen " bedeutet: die Methode (den Funktionsaufruf) einfach an einem beliebigen Objekt ausprobieren, anstatt zuerst den Typ des Objekts zu überprüfen, um festzustellen, ob die Methode überhaupt einen gültigen Aufruf für einen solchen Typ darstellt.
Nennen wir es "Probieren Sie die Methoden aus, prüfen Sie nicht den Typ" tippen, "Methodenaufruf-Typ-Prüfung" oder einfach "Methodenaufruf-Typisierung" kurz gesagt.
In der folgenden längeren Erklärung werde ich dies genauer erläutern und Ihnen helfen, den lächerlichen, esoterischen und verworrenen Begriff "Duck Typing" zu verstehen.
Längere Erklärung:
DIE DIE!
Python erfüllt dieses Konzept. Betrachten Sie diese Beispielfunktion:
def func(a):
a.method1()
a.method2()
Wenn das Objekt (Eingabeparameter a
) kommt in die Funktion func()
wird die Funktion (zur Laufzeit) versuchen, alle für dieses Objekt angegebenen Methoden aufzurufen (nämlich: method1()
y method2()
im obigen Beispiel), anstatt zuerst zu prüfen, ob a
ist ein "gültiger Typ", der über diese Methoden verfügt.
Also, es ist ein handlungsorientiert Versuch zur Laufzeit, NICHT eine typbezogen bei der Kompilierung oder während der Laufzeit prüfen.
Sehen Sie sich dieses dumme Beispiel an:
def func(duck_or_duck_like_object):
duck_or_duck_like_object.quack()
duck_or_duck_like_object.walk()
duck_or_duck_like_object.fly()
duck_or_duck_like_object.swim()
Daher kommt die lächerliche Formulierung:
Wenn sie wie eine Ente läuft und wie eine Ente quakt, dann ist sie eine Ente.
Das Programm, das "duck typing" verwendet, soll einfach alle Methoden ausprobieren, die für das Objekt aufgerufen werden (in diesem Beispiel oben: quack()
, walk()
, fly()
y swim()
), OHNE überhaupt die Typ des Objekts! Es probiert einfach die Methoden aus! Wenn sie funktionieren, großartig, für alles, was die "Enten-Typisierungs"-Sprache weiß oder sich darum kümmert, IST ES (das Objekt, das an die Funktion übergeben wird) EINE ENTE!--weil alle (Enten-ähnlichen) Methoden bei ihm funktionieren.
(Ich fasse meine eigenen Worte zusammen):
Eine "duck typed" Sprache überprüft ihren Typ nicht (weder zur Kompilier- noch zur Laufzeit) - es ist ihr egal. Sie probiert die Methoden einfach zur Laufzeit aus. Wenn sie funktionieren, großartig. Wenn nicht, dann soll sie einen Laufzeitfehler auslösen.
Das ist Duck-Typing.
Ich habe diese lächerliche "Enten"-Erklärung so satt (denn ohne diese vollständige Erklärung macht sie überhaupt keinen Sinn!), und andere anscheinend auch. Beispiel: von Antwort von BKSpurgeon hier (meine Hervorhebung im Fettdruck):
("Wenn es läuft wie eine Ente und quakt wie eine Ente, dann ist es eine Ente.") - JA! aber was bedeutet das??!"
Jetzt verstehe ich es: Probieren Sie die Methode einfach an jedem beliebigen Objekt aus, anstatt zuerst den Typ des Objekts zu überprüfen.
Ich nenne dies "Laufzeitprüfung", bei der das Programm einfach die aufgerufenen Methoden ausprobiert, ohne zu wissen, ob das Objekt über diese Methoden verfügt, anstatt die Typ des Objekts, um zu wissen, dass das Objekt über diese Methoden verfügt. denn das macht einfach mehr Sinn. Aber... das ist zu lang, um es auszusprechen, also verwirren sich die Leute lieber jahrelang gegenseitig, indem sie lächerliche, aber eingängige Dinge sagen wie "Enten-Tippen".
Nennen wir dies stattdessen: "Probieren Sie die Methoden aus, prüfen Sie nicht den Typ" tippen. Oder, vielleicht: "Methodenaufruf-Typ-Prüfung" ( "Methodenaufruf-Typisierung" kurz), oder "indirekte Typüberprüfung durch Methodenaufrufe" da es den Aufruf einer bestimmten Methode als "ausreichenden Beweis" dafür verwendet, dass das Objekt vom richtigen Typ ist, anstatt den Typ des Objekts direkt zu überprüfen.
Beachten Sie, dass diese "Methodenaufruf-Typüberprüfung" (sonst verwirrenderweise "Duck Typing" genannt) eine Art von dynamische Schreibweise . Aber, NICHT alle dynamische Schreibweise ist notwendigerweise eine "Methodenaufruf-Typüberprüfung", denn dynamische Schreibweise oder die Typüberprüfung zur Laufzeit kann auch durch die tatsächliche Überprüfung des Typs eines Objekts anstatt einfach zu versuchen, die Methoden des Objekts in der Funktion aufzurufen, ohne dessen Typ zu kennen.
Lesen Sie auch:
- https://en.wikipedia.org/wiki/Duck_typing --> Suchen Sie auf der Seite nach "run", "run time" und "runtime".
Wikipedia bietet eine recht ausführliche Erklärung:
http://en.wikipedia.org/wiki/Duck_typing
duck typing ist eine Form der dynamischen Typisierung, bei der die aktuelle Satz von Methoden und Eigenschaften die gültige Semantik bestimmt, und nicht als seine Vererbung von einer bestimmten Klasse oder der Implementierung einer bestimmten Schnittstelle.
Der wichtige Hinweis ist wahrscheinlich, dass sich ein Entwickler bei der Duck-Typisierung mehr mit den Teilen des Objekts beschäftigt, die konsumiert werden, als mit dem eigentlichen zugrunde liegenden Typ.
Ich weiß, dass ich keine pauschale Antwort gebe. In Ruby deklarieren wir nicht die Typen von Variablen oder Methoden - alles ist einfach eine Art Objekt. Die Regel lautet also "Klassen sind keine Typen".
In Ruby ist die Klasse nie (OK, fast nie) der Typ. Stattdessen wird der Typ eines Objekts eher dadurch definiert, was dieses Objekt tun kann. In Ruby nennen wir das "duck typing". Wenn ein Objekt wie eine Ente läuft und wie eine Ente spricht, dann ist der Interpreter froh, wenn er es so behandeln kann, als wäre es eine Ente.
Sie können zum Beispiel eine Routine schreiben, um einer Zeichenkette Liedinformationen hinzuzufügen. Wenn Sie von einem C#- oder Java-Hintergrund kommen, könnten Sie versucht sein, dies zu schreiben:
def append_song(result, song)
# test we're given the right parameters
unless result.kind_of?(String)
fail TypeError.new("String expected") end
unless song.kind_of?(Song)
fail TypeError.new("Song expected")
end
result << song.title << " (" << song.artist << ")" end
result = ""
append_song(result, song) # => "I Got Rhythm (Gene Kelly)"
Machen Sie sich die Duck-Typisierung von Ruby zu eigen, und Sie werden etwas viel Einfacheres schreiben:
def append_song(result, song)
result << song.title << " (" << song.artist << ")"
end
result = ""
append_song(result, song) # => "I Got Rhythm (Gene Kelly)"
Sie brauchen den Typ der Argumente nicht zu überprüfen. Wenn sie << (im Falle von result) oder Titel und Interpret (im Falle von song) unterstützen, wird alles funktionieren. Wenn nicht, wird Ihre Methode trotzdem eine Ausnahme auslösen (genauso wie sie es getan hätte, wenn Sie die Typen geprüft hätten). Aber ohne die Prüfung ist Ihre Methode plötzlich viel flexibler. Sie könnten ihr ein Array, eine Zeichenkette, eine Datei oder jedes andere Objekt übergeben, das mit << anhängt, und es würde einfach funktionieren.
Ein Blick auf die Sprache selbst kann helfen; mir hilft das oft (ich bin kein englischer Muttersprachler).
Sur duck typing
:
1) das Wort typing
bedeutet nicht, dass man auf einer Tastatur tippt (wie ich es mir immer vorgestellt habe), sondern es bedeutet, dass man " Was für ein Ding ist dieses Ding? "
2) das Wort duck
drückt aus, wie diese Bestimmung erfolgt; es ist eine Art "lose" Bestimmung, wie in: " Wenn es wie eine Ente läuft ... dann ist es eine Ente ". Es ist "lose", weil das Ding eine Ente sein kann oder auch nicht, aber ob es tatsächlich eine Ente ist, spielt keine Rolle; was zählt, ist, dass ich mit ihr tun kann, was ich mit Enten tun kann, und dass ich Verhaltensweisen erwarte, die von Enten gezeigt werden. Ich kann sie mit Brotkrümeln füttern, und sie kann auf mich zugehen, mich angreifen oder sich zurückziehen ... aber sie wird mich nicht verschlingen, wie es ein Grizzly tun würde.
Good Will Hunting - Matt Damon Duck Tippen Szene
CHUCKIE : Alles klar, haben wir ein Problem?
CLARK : Das ist kein Problem. Ich hatte nur gehofft, Sie könnten mir einen Einblick geben, was Enten-Typing eigentlich ist? Ich behaupte, dass das Binden von Enten nicht gut definiert ist, und auch nicht stark
WILL : [unterbricht] und auch nicht starkes Tippen. Natürlich ist das Ihre Behauptung. Sie sind ein Student im ersten Jahr: Sie haben gerade einen Artikel über Duck Typing gelesen, wahrscheinlich auf StackOverflow, und Sie werden bis nächsten Monat davon überzeugt sein, wenn Sie zur Gang of Four kommen, und dann werden Sie darüber reden, wie Google Go und Ocaml statistisch typisierte Sprachen mit struktureller Sub-Tying Konstruktion sind. Das wird bis zum nächsten Jahr dauern, bis Sie hier wahrscheinlich Matz wiederkäuen und über die Utopie vor Ruby 3.0 und die speicherzuteilenden Auswirkungen der Untertypisierung auf den GC sprechen.
CLARK: [verblüfft] Das werde ich in der Tat nicht, denn Matz unterschätzt drastisch die Auswirkungen von -
WILL : "Matz unterschätzt die Auswirkungen der GC von Ruby 3.0 auf die Leistung dramatisch. Das haben Sie von Donald Knuth, The Art of Computer Programming, Seite 98, richtig? Ja, das habe ich auch gelesen. Wolltest du das ganze Ding für uns plagiieren - hast du irgendwelche eigenen Gedanken zu diesem Thema? Oder ist das dein Ding, du kommst in einen Slack-Thread, liest irgendeine obskure Passage auf r/ruby und tust dann so, als wäre es deine eigene Idee, nur um ein paar Mädchen zu beeindrucken und meinen Freund zu blamieren?
(Clark ist fassungslos)
WILL : Das Traurige an einem Typen wie dir ist, dass du in etwa 50 Jahren anfangen wirst, selbst nachzudenken, und du wirst zu der Erkenntnis kommen, dass es drei Gewissheiten im Leben gibt. Erstens: Tu das nicht. Und zweitens: Wenn es wie eine Ente läuft, dann ist es auch eine Ente. Und drittens: Du hast hundertfünfzig Riesen für eine Ausbildung ausgegeben, die du für null Cent über eine Stack-Overflow-Antwort von Ben Koshy hättest bekommen können.
CLARK : Ja, aber ich werde einen Abschluss haben, und Sie werden meinen Kindern auf dem Weg zum Skifahren ein paar billige Htmls am Drive-Thru servieren.
WILL : [lächelt] Ja, vielleicht. Aber zumindest werde ich nicht unoriginell sein.
(ein Schlag)
WILL: haben Sie ein Problem damit? Ich denke, wir können nach draußen gehen und ein paar "Advent of Code"-Übungen machen?
Clark: Es gibt kein Problem
Einige Zeit später:
WILL: Mögen Sie Äpfel?
Clark ist verblüfft. Hm?
WILL: Wie magst du die Äpfel? (Boom: Will knallt einen Brief gegen ein Fenster.) Ich habe ein Angebot von Google! (Zeigt Clark die Zusage und zeigt seine Antwort auf das Vorstellungsgespräch: die richtige Antwort auf einen Bubble-Sortieralgorithmus und ein Bild einer laufenden Ente)
Das Ende
(Dies ist eine Fußnote zum alte Antwort hier :)