vilkår implisitt og eksplisitt ta litt tid å bli vant til når du først høre dem. Når du hører dem i form av programmering hva betyr dette for deg? Er en måte bedre enn en annen? Her vil vi gå over hvert av disse ideene og gi eksempler med noen design mønster fordeler som kan komme fra dem.
Vilkårene
I programmering, implisitt er ofte brukt for å referere til noe som er gjort for deg av andre koden bak kulissene., Eksplisitt er manuell tilnærming til å oppnå den endringen du ønsker å ha med å skrive ut instruksjoner for å gjøres eksplisitt. I mindre bilde, implisitt og eksplisitt er ofte uttrykkene som er brukt til støping typer i den typen du ville ha det til å være. I det store bildet, kan du bli snakker om convention over configuration hvor konvensjonen er det som er implisitt gjort for deg med en kode base eller rammeverk og konfigurasjon er rett og slett eksplisitt innstillinger.,
Det er også forskjeller på hensiktsmessigheten eller fordel, enten for bruk, avhengig av programmering aktuelle språket, og om språket er statisk skrevet eller dynamisk skrev inn. Det avhenger også av om ting som kan være avledet fra en kjøretid eller under kompilering. På grunn av disse faktorene, noe som gjør et krav om at en metode er bedre enn en annen kan bare muligens være sant innenfor snevre rammer som du må ta hensyn til design for programmeringsspråk og programmer i spørsmålet.,
Et eksempel på implisitte og eksplisitte type casting i C er som følger:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
Her variabelen navn implicit og explicit ble definert til å være av typen int. En gang gitt en verdi 4.5 den implisitte versjonen har kompilatoren konvertere det normalt vil være en dupp eller dobbeltrom skriv til et heltall, mens den eksplisitte versjon eksplisitt har kastet det til et heltall med bruk av (int) som hva kaster type.,
Statisk skrevet språk
I statisk skrevet språk som Rust et stort flertall av verdiskaping og tildeling vil ha eksplisitte type anmerkning krav med et unntak for uansett hvor kompilatoren kan antyde den type. Følgende er et eksempel som viser eksplisitt og implisitt typer i Rust.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
Her metode add_one er eksplisitt om input type og output type., Antall 1 blir lagt til her er implisitt laget en u8 nummeret på samling tid som kontekst bidrar til å utlede hvilken type og tillegg for u8 er bare gjennomført for å arbeide med u8 tall. Den siste linjen er implisitt skrevet for å være en u8 siden metoden i seg selv definerer type som vil bli returnert.
Hva kan utledes i Rust er ganske imponerende med bruk av generiske legemidler. Men bruk av inferens er begrenset til ting som kan bli kjent på kompilere tid., Hvis det kan ikke være kjent på kompilere tid så du må eksplisitt angi typen på noe punkt i oppgaven. Ta følgende metode definisjon:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
Her T kan være hvilken som helst type som implementerer den egenskap Add. T::Output type er definert når Legge til trekk som er definert for dine spesifikke typen, og det er vanligvis de samme type som T seg selv i dette tilfellet. Hvis vi nå gi to tall som parametre kompilatoren vil antyde typen til det.,
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 kjører over koden x utledes til å være den type i32. y og z eksempler krever input parameter type for å bli kjent når gitt til den funksjonen som den slutning for T::Output er ikke nødvendigvis det samme som det T kan forstås som. Det ville standard til i32 og deretter tilordne en i32 som u8 eller u32 er rett og slett feil.,
Dynamisk skrevet språk
Nå med dynamisk skrevet språk, har du å bekymre deg mindre om typer, per se, og mer om implisitt eller eksplisitt objekter eller atferd. Modellering kode rundt objekter som har samme atferd er det som er kjent som duck å skrive noe som er en høyere domenet av å tenke i objekt-orientert programmering hvor håndtering av de gjenstander som er implisitt. Mens modellering kode rundt spesifikt objekt klasser er mye som ved hjelp av eksplisitt eller implisitt å skrive., Men når du godta alle slags objekt som input, så koden i denne delen, må du enten håndtere forskjellige objekter uttrykkelig eller hånd som ansvar av andre steder.
For avklaring, når du skriver kode for å håndtere ulike typer av ting, da du skriver eksplisitt kode. Men når den samme koden har allerede blitt skrevet og du bruker det med en enkel metode ringe, så atferd i denne nye sammenhengen er da implisitt. Implisitt blir ting gjort som om automatisk og håndteres utenfor din nåværende omfang.,
I Ruby, de fleste typer har en design for eksplisitt eller implisitt konvertering. Ideen er implisitt konvertering metoder er ment å bli brukt i implisitt sammenhenger og den eksplisitte konverteringer er ment for utviklere å skrive inline i langt flere sammenhenger. La meg vise dette med et eksempel.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
Her eksplisitt eksempel gjør det veldig tydelig for leseren at vi er konvertering String objekter til en Integer objekt og utføre addisjon mellom de to., Og det implisitte eksempel ikke er så opplagt for leseren som Array.new metode implisitt kaller to_int metode på hva parameteren er det gitt. Den Heltall klasse har metoden to_int definert på hver forekomst av det som bare tilbake selv. Hvis du skriver 42.to_int du bare komme tilbake 42. Denne bruken av ved hjelp av implisitt konvertering som en inngang vakt for metoden anrop er en flott design for type sikkerhet ved design. Her er hva som skjer hvis du gi det feil type objekt som input som ikke angi to_int.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
Ikke bare det mislykkes, men det gir oss en nyttig melding om at en implisitt konvertering ble forsøkt og forteller klasse, objekt gitt og klasse objektet det forventer. Implisitt konvertering metoder i Ruby er en måte å si dette objektet virkelig er hva du forventer. Og eksplisitt konvertering er rett og slett å gjøre konverteringen til den type forventet.
Ruby har implisitte og eksplisitte valg for mange av sine viktige objekter.,
Ruby har også et par klasser med klasse metoder som enten vil gjøre en implisitt konvertering eller gå tilbake nil og at metoden navn er try_convert.
Vi kan følge Ruby ‘ s eksempel med Array.new og har en god vakt for den slags parametere vi er gitt ved å utforme implisitte konverteringer for våre egne tilpassede typer. For dette eksempelet, siden to_f er en eksplisitt konvertering til en Float nummer i Ruby vi vil bruke as_ som prefiks i stedet for to_., Her er et enkelt eksempel på implicitness som et mønster for sikkerhet.
Nå dette vil hjelpe andre utviklere som bruker Bar klassen til å ikke gi det som en inkompatibel parameter. Det følger med en konvensjon i Ruby som språk og burde være mye mer enkelt for utviklere å forstå med mer nyttig feil. Når du har andre ting du ønsker å konvertere til en Foo objekt deretter kan du angi et as_f metode på det for en eksplisitt konvertering og utvikleren som bruker det nye objektet vil bli eksplisitt i sin bruk Bar.new(Baz.new.as_f)., Dette sørger for at koden vil fungere i så mye som Bar og Foo er allerede arbeider med.
Oppsummering
lov av implisitt og eksplisitt koding, og implisitt og eksplisitt-koden, som er definert av konteksten for gjennomføring av ytterligere atferd eller papirtype/casting. Spesielt, implisitte eller eksplisitte metoder er definert av de sammenhenger de er ment å bli brukt. Implisitt koden kan være en veldig fin opplevelse hvis ting er et godt navn som den holder ting enkelt.,
Imidlertid implisitt kode, kode å gjøre ting bak kulissene for deg, kan også være en vanskelig sak å løse når det gjøres feil. Eksplisitt koden gjør koden tydelig når du ser på det som foregår av hva som blir gjort er allerede lagt ut før deg, og du trenger ikke å spore opp problemer andre steder, men generelt betyr mye mer arbeid å skrive det. På egen hånd, kan det bli for overveldende, så å finne en god balanse mellom de to er ofte den beste løsningen. Være tydelig når du må, og implisitt når design og navn begreper er enkelt å forstå., Det vil gjøre for en mer praktisk erfaring med utviklingsarbeid.