udtrykkene implicit og eksplicit tager nogle at vænne sig til, når du først hører dem. Når du hører dem med hensyn til programmering, hvad betyder det nøjagtigt for dig? Er en måde bedre end en anden? Her vil vi gå over hver af disse ideer og give eksempler med nogle design mønster fordele, der kan komme fra dem.
udtrykkene
i programmering bruges implicit ofte til at henvise til noget, der er gjort for dig ved anden kode bag kulisserne., Eksplicit er den manuelle tilgang til at udføre den ændring, du ønsker at have, ved at skrive instruktionerne, der skal udføres eksplicit. I det mindre billede, implicit og eksplicit er ofte udtryk, der bruges til at støbe typer ind på den type, du ville have den til at være. I det større billede kan du tale om konvention over konfiguration, hvor konvention er det, der implicit gøres for dig af en kodebase eller ramme, og konfiguration er simpelthen eksplicitte indstillinger.,
der er også forskelle i hensigtsmæssighed eller fordel for enten brug afhængigt af det pågældende programmeringssprog, og om Sproget er statisk indtastet eller dynamisk indtastet. Det afhænger også af, om tingene kan udledes fra en køretid eller under kompilering. På grund af disse faktorer, gør en påstand om, at en metode er bedre end en anden kan kun muligvis være sandt inden for snævre sammenhænge, som du er nødt til at tage hensyn til design for programmeringssprog og programmer pågældende.,
Et eksempel på implicit og eksplicit type casting i C er som følger:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
Her variabelnavne implicit og explicit var defineret til at være af typen int. Når du har givet det en værdi 4.5 den implicitte version har compiler konvertere, hvad der normalt ville være en float eller double type til et heltal, der henviser til, at den eksplicitte version har udtrykkeligt kaste det til et heltal med brug af (int) er hvad kaster type.,
statisk-indtastede sprog
i statisk-indtastede sprog som Rust et stort flertal af værdiskabelse og tildeling vil have eksplicitte type annotation krav med en undtagelse for hvor compileren kan udlede typen. Følgende er et eksempel, der viser eksplicitte og implicitte typer i Rust.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
Her er metoden add_one eksplicit om indgangstypen og udgangstypen., Antallet 1 bliver tilføjet her er implicit lavet en u8 nummer på udarbejdelse tid som led hjælper med at udlede, hvilken type og over for u8 er kun gennemført for at arbejde med u8 tal. Den sidste linje er implicit skrevet til at være en u8 da metoden selv definerer den type, der vil blive returneret.
hvad der kan udledes i Rust er temmelig imponerende ved brug af generiske stoffer. Men brugen af inferens er begrænset til ting, der kan være kendt på kompileringstidspunktet., Hvis det ikke kan kendes på kompileringstidspunktet, skal du eksplicit definere typen på ethvert tildelingspunkt. Tag følgende metode definition:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
Her T kan være enhver type, der gennemfører træk Add. T::Output type er defineret, når Tilføje et træk, der er defineret for din specifikke type, og er generelt den samme type som T selv i dette tilfælde. Nu, hvis vi giver to tal som parametre, vil kompilatoren udlede typen til den.,
let x = add_both(3 , 4 ); // implicit typelet y: u8 = add_both(3u8 , 4u8 ); // explicit typelet z: u32 = add_both(3u32, 4u32); // explicit type
Når jeg kører ovenstående kode xudledes at være typen i32. Eksemplerne y og z kræver, at inputparametertyperne kendes, når de leveres til funktionen som inferens for T::Output ikke nødvendigvis er det samme som det, T kan udledes til as. Det vil som standard i32 og så tildele en i32 som u8 eller u32, er simpelthen forkert.,
dynamisk typede sprog
nu med dynamisk typede sprog skal du bekymre dig mindre om typer i sig selv og mere om implicitte eller eksplicitte objekter eller adfærd. Modelleringskode omkring objekter, der har samme opførsel, er det, der er kendt som duck typing, hvilket er et højere tænkningsdomæne i objektorienteret programmering, hvor håndtering af disse objekter er implicit. Mens modellering af koden omkring specifikke objektklasser er meget som at bruge eksplicit eller implicit typing., Men når du accepterer enhver form for objekt som input, skal koden i det afsnit enten håndtere forskellige objekter eksplicit eller aflevere dette ansvar andetsteds.
for afklaring, når du skriver kode til at håndtere forskellige slags ting, så skriver du eksplicit kode. Men når denne samme kode allerede er skrevet, og du genbruger den med et simpelt metodekald, så er opførslen i denne nye sammenhæng implicit. Implicit bliver tingene gjort som om automatisk og håndteres uden for dit nuværende omfang.,
i Ruby har de fleste typer et design til eksplicit eller implicit konvertering. Ideen er, at implicitte konverteringsmetoder er beregnet til at blive brugt i implicitte sammenhænge, og de eksplicitte konverteringer er beregnet til udviklere at skrive inline i meget flere sammenhænge. Lad mig demonstrere dette ved eksempel.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
Her bliver den eksplicitte eksempel gør det meget klart for læseren, at vi er konvertering af String objekter til en Integer objekt og udføre addition mellem de to., Og det implicitte eksempel er ikke så indlysende for læseren, da Array.new – metoden implicit kalder to_int-metoden på den parameter, den er givet. Heltalsklassen har metoden to_int defineret på hver forekomst af den, der blot returnerer selv. Hvis du skriver 42.to_int, skal du blot komme tilbage 42. Denne brug af at bruge implicit konvertering som en indgangsbeskyttelse til metodekald er et fantastisk design til typesikkerhed efter design. Her er hvad der sker, hvis du giver det den forkerte slags objekt som input, som ikke definerer to_int.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
det mislykkes ikke kun, men det giver os en nyttig besked om, at en implicit konvertering blev forsøgt og fortæller klassen af objekt, der er givet, og den klasse af objekt, den forventer. Implicitte konverteringsmetoder i Ruby er en måde at sige, at dette objekt virkelig er, hvad du forventer. Og eksplicit konvertering gør simpelthen konverteringen til den forventede type.Ruby har implicitte og eksplicitte muligheder for mange af sine kerneobjekter.,Ruby har også et par klasser med klassemetoder, der enten vil gøre en implicit konvertering eller returnere nul, og det metodenavn er try_convert.
Vi kan følge Rubys eksempel med Array.new og har en god vagt for den slags inputparametre, vi får ved at designe implicitte konverteringer til vores egne brugerdefinerede typer. Til dette eksempel, da to_f er en eksplicit konvertering til en Float nummer i Ruby vi vil bruge as_ som et præfiks i stedet for to_., Her er et grundlæggende eksempel på implicithed som et mønster for sikkerhed.
nu vil dette hjælpe andre udviklere, der bruger Bar klassen for ikke at videregive den som en inkompatibel parameter. Det følger en konvention inden for Ruby-sproget og bør være meget lettere for udviklere at forstå med mere nyttige fejl. Når du har andre objekter, som du ønsker at konvertere til et Foo objekt, så kan du angive en as_f metode på det for en eksplicit konvertering, og den udvikler, der bruger det nye objekt vil være eksplicit i sin brug Bar.new(Baz.new.as_f)., Dette sikrer, at koden fungerer så meget som Bar og Foo allerede fungerer.
resum.
handlingen med implicit og eksplicit kodning og implicit og eksplicit kode defineres ved kontekst for udførelse af yderligere adfærd eller typeindstilling / støbning. Specifikt defineres implicitte eller eksplicitte metoder af de sammenhænge, hvor de er beregnet til at blive brugt. Implicit kode kan være en meget flot oplevelse, hvis tingene er godt navngivet, da det holder tingene enkle.,implicit kode, kode, der gør ting bag kulisserne for dig, kan dog også være et vanskeligt problem at løse, når det gøres forkert. Eksplicit kode gør koden klar, når du ser på den, da specifikationerne for, hvad der gøres, allerede er lagt ud for dig, og du behøver ikke at spore problemer andre steder, men betyder generelt meget mere arbejde med at skrive det. På egen hånd kan det blive overvældende, så at finde en ordentlig balance mellem de to er ofte den bedste løsning. Vær eksplicit, når du skal, og implicit, når design og navngivning begreber er let at forstå., Det vil gøre for en mere bekvem udvikling oplevelse.