Die Begriffe implizit und explizit nehmen einige gewöhnungsbedürftig, wenn Sie sie zum ersten Mal hören. Wenn Sie sie in Bezug auf die Programmierung hören, was genau bedeutet das für Sie? Ist der eine Weg besser als der andere? Hier werden wir über jede dieser Ideen gehen und Beispiele mit einigen Design-Muster Vorteile, die von ihnen kommen können.
Die Begriffe
In der Programmierung wird implizit oft verwendet, um sich auf etwas zu beziehen, das von anderem Code hinter den Kulissen für Sie erledigt wird., Explizit ist der manuelle Ansatz zum Ausführen der Änderung, die Sie haben möchten, indem Sie die Anweisungen explizit schreiben. Im kleineren Bild werden implizit und explizit häufig Begriffe verwendet, um Typen in den Typ umzuwandeln, für den Sie sie haben möchten. Im größeren Bild sprechen Sie möglicherweise von Konvention über Konfiguration, wobei Konvention implizit von einer Codebasis oder einem Framework für Sie durchgeführt wird und Konfiguration einfach explizite Einstellungen sind.,
Es gibt auch Unterschiede hinsichtlich der Angemessenheit oder des Nutzens für beide Verwendungszwecke, abhängig von der fraglichen Programmiersprache und davon, ob die Sprache statisch typisiert oder dynamisch typisiert ist. Es hängt auch davon ab, ob Dinge aus einer Laufzeit oder während der Kompilierung abgeleitet werden können. Aufgrund dieser Faktoren kann die Behauptung, dass eine Methodik besser ist als eine andere, möglicherweise nur in engen Kontexten zutreffen, da Sie das Design für die betreffenden Programmiersprachen und Programme berücksichtigen müssen.,
Ein Beispiel für implizites und explizites Typ-Casting in C ist wie folgt:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
Hier wurden die Variablennamen implicit und explicit als Typ intdefiniert. Sobald der Wert 4.5 in der impliziten Version den Wert 4.5 hat der Compiler einen normalerweise Float-oder Double-Typ in eine Ganzzahl konvertieren, während die explizite Version ihn explizit in eine Ganzzahl umgewandelt hat mit der Verwendung von (int), was den Typ,
Statisch typisierte Sprachen
In statisch typisierten Sprachen wie Rust hat eine überwiegende Mehrheit der Wertschöpfung und Zuweisung explizite Typanmerkungsanforderungen mit einer Ausnahme, wo immer der Compiler den Typ ableiten kann. Das folgende Beispiel zeigt explizite und implizite Typen in Rust.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
Hier ist die Methode add_one explizit über den Eingabetyp und den Ausgabetyp., Die hier hinzugefügte Nummer 1 wird implizit zu einer u8 – Nummer zur Kompilierungszeit gemacht, da der Kontext den Typ und die Addition für u8 ableitet u8 ist nur für die Arbeit mit u8 – Nummern implementiert. Die letzte Zeile wird implizit als u8 da die Methode selbst den Typ definiert, der zurückgegeben wird.
Was in Rust abgeleitet werden kann, ist mit der Verwendung von Generika ziemlich beeindruckend. Die Verwendung von Inferenz ist jedoch auf Dinge beschränkt, die zur Kompilierungszeit bekannt sind., Wenn es zur Kompilierungszeit nicht bekannt ist, müssen Sie den Typ an einem beliebigen Zuweisungspunkt explizit definieren. Nehmen Sie die folgende Methodendefinition:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
Hier T kann jeder Typ sein, der das Merkmal implementiert Add. Der Typ T::Output wird definiert, wenn das Add-Merkmal für Ihren spezifischen Typ definiert ist, und ist in diesem Fall im Allgemeinen derselbe Typ wie T selbst. Wenn wir nun zwei Zahlen als Parameter angeben, leitet der Compiler den Typ darauf ab.,
let x = add_both(3 , 4 ); // implicit typelet y: u8 = add_both(3u8 , 4u8 ); // explicit typelet z: u32 = add_both(3u32, 4u32); // explicit type
Wenn ich den obigen Code ausführe x wird der Typ i32abgeleitet. Die Beispiele y und z erfordern, dass die Eingabeparametertypen bekannt sind, wenn sie der Funktion als Inferenz für T::Output zur Verfügung gestellt werden. Es würde standardmäßig i32 und dann eine i32 als u8 oder u32 ist einfach falsch.,
Dynamisch typisierte Sprachen
Jetzt müssen Sie sich bei dynamisch typisierten Sprachen weniger um Typen als vielmehr um implizite oder explizite Objekte oder Verhaltensweisen kümmern. Das Modellieren von Code um Objekte mit demselben Verhalten wird als Ententypisierung bezeichnet, die in der objektorientierten Programmierung, in der der Umgang mit diesen Objekten implizit ist, eine höhere Denkdomäne darstellt. Während die Modellierung des Codes um bestimmte Objektklassen ähnlich ist wie die Verwendung expliziter oder impliziter Typisierung., Wenn Sie jedoch eine Art von Objekt als Eingabe akzeptieren, muss der Code in diesem Abschnitt entweder explizit mit verschiedenen Objekten umgehen oder diese Verantwortung an anderer Stelle abgeben.
Zur Verdeutlichung, wenn Sie Code schreiben, um verschiedene Arten von Dingen zu behandeln, dann schreiben Sie expliziten Code. Wenn derselbe Code jedoch bereits geschrieben wurde und Sie ihn mit einem einfachen Methodenaufruf wiederverwenden, ist das Verhalten in diesem neuen Kontext implizit. Implizit werden Dinge wie automatisch gemacht und außerhalb Ihres aktuellen Bereichs behandelt.,
In Ruby haben die meisten Typen ein Design für explizite oder implizite Konvertierung. Die Idee ist, dass die impliziten Konvertierungsmethoden in impliziten Kontexten verwendet werden sollen und die expliziten Konvertierungen für Entwickler gedacht sind, um in viel mehr Kontexten inline zu schreiben. Lassen Sie mich dies anhand eines Beispiels demonstrieren.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
Hier macht das explizite Beispiel dem Leser sehr deutlich, dass wir String Objekte in ein Integer Objekt konvertieren und eine Addition zwischen den beiden durchführen., Und das implizite Beispiel ist für den Leser nicht so offensichtlich, da dieArray.new – Methode implizit die to_int-Methode für jeden Parameter aufruft. In der Integer-Klasse ist für jede Instanz die Methode to_int definiert, die einfach self zurückgibt. Wenn Sie 42.to_int schreiben, erhalten Sie einfach 42zurück. Diese Verwendung der impliziten Konvertierung als Eingabewächter für Methodenaufrufe ist ein großartiges Design für die Typsicherheit. Folgendes passiert, wenn Sie ihm die falsche Art von Objekt als Eingabe geben, das to_intnicht definiert.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
Schlägt nicht nur fehl, sondern gibt uns auch eine hilfreiche Nachricht, dass eine implizite Konvertierung versucht wurde und teilt die Klasse des angegebenen Objekts und die Klasse des erwarteten Objekts mit. Implizite Konvertierungsmethoden in Ruby können sagen, dass dieses Objekt wirklich das ist, was Sie erwarten. Und die explizite Konvertierung führt einfach dazu, dass die Konvertierung in den erwarteten Typ erfolgt.
Ruby hat implizite und explizite Optionen für viele seiner Kernobjekte.,
Ruby hat auch einige Klassen mit Klassenmethoden, die entweder eine implizite Konvertierung durchführen oder nil zurückgeben, und dieser Methodenname ist try_convert.
Wir können Rubys Beispiel mit Array.new folgen und haben einen guten Schutz für die Art von Eingabeparametern, die wir erhalten, indem wir implizite Konvertierungen für unsere eigenen benutzerdefinierten Typen entwerfen. Da to_f in Ruby eine explizite Konvertierung in eine Gleitkommazahl ist, verwenden wir für dieses Beispiel as_ als Präfix anstelle von to_., Hier ist ein grundlegendes Beispiel für Implizitheit als Muster für Sicherheit.
Dies hilft nun anderen Entwicklern, die die Bar – Klasse verwenden, um sie nicht als inkompatiblen Parameter zu übergeben. Es folgt einer Konvention innerhalb der Ruby-Sprache und sollte für Entwickler mit hilfreicheren Fehlern viel einfacher zu verstehen sein. Wenn Sie andere Objekte haben, die Sie in ein Foo-Objekt konvertieren möchten, können Sie eine as_f – Methode für eine explizite Konvertierung definieren, und der Entwickler, der dieses neue Objekt verwendet, ist explizit in seiner Verwendung Bar.new(Baz.new.as_f)., Dies stellt sicher, dass der Code so gut funktioniert, wie Bar und Foo bereits funktionieren.
Zusammenfassung
Der Akt der impliziten und expliziten Codierung und des impliziten und expliziten Codes wird durch den Kontext der Ausführung von zusätzlichem Verhalten oder Typeinstellung / Casting definiert. Insbesondere implizite oder explizite Methoden werden durch die Kontexte definiert, in denen sie verwendet werden sollen. Impliziter Code kann eine sehr schöne Erfahrung sein, wenn die Dinge gut benannt sind, da er die Dinge einfach hält.,
Impliziter Code, Code, der Dinge hinter den Kulissen für Sie tut, kann jedoch auch ein schwieriges Problem sein, wenn er falsch gemacht wird. Expliziter Code macht den Code klar, wenn Sie ihn betrachten, da die Einzelheiten dessen, was getan wird, bereits vor Ihnen festgelegt sind und Sie keine Probleme an anderer Stelle aufspüren müssen, sondern im Allgemeinen viel mehr Arbeit beim Schreiben bedeuten. Alleine kann es überwältigend werden, so dass es oft die beste Lösung ist, ein angemessenes Gleichgewicht zwischen den beiden zu finden. Seien Sie explizit, wenn Sie müssen, und implizit, wenn die Design-und Benennungskonzepte leicht zu verstehen sind., Es wird für eine bequemere Entwicklungserfahrung sorgen.