villkoren implicita och explicita tar lite att vänja sig vid när du först hör dem. När du hör dem när det gäller programmering vad exakt betyder det för dig? Är ett sätt bättre än ett annat? Här går vi över var och en av dessa idéer och ger exempel med några designmönsterfördelar som kan komma från dem.
termerna
i programmeringen används implicit ofta för att hänvisa till något som görs för dig med annan kod bakom kulisserna., Explicit är det manuella sättet att utföra den förändring du vill ha genom att skriva ut instruktionerna som ska göras uttryckligen. I den mindre bilden, implicit och explicit är ofta termer som används för gjutning typer i den typ du skulle ha det att vara. I den större bilden kan du prata om konvention över konfiguration där konventionen är vad som implicit görs för dig med en kodbas eller ram och konfiguration är helt enkelt explicita inställningar.,
det finns också skillnader i lämplighet eller nytta för antingen användning beroende på programmeringsspråket i fråga och om språket statiskt skrivs eller dynamiskt skrivs. Det beror också på om saker kan härledas från en körtid eller under sammanställning. På grund av dessa faktorer, att göra ett påstående om att en metod är bättre än en annan kan endast möjligen vara sant inom smala sammanhang som du måste ta hänsyn till utformningen av programmeringsspråk och program i fråga.,
ett exempel på implicit och explicit typgjutning i C är följande:
int implicit;implicit = 4.5;int explicit;explicit = (int)4.5;
här definierades variabelnamnenimplicit ochexplicit för att vara av typenint. En gång gett ett värde 4.5 den implicita versionen har kompilatorn konvertera vad som normalt skulle vara en flottör eller dubbel typ till ett heltal medan den explicita versionen uttryckligen har gjutit den till ett heltal med hjälp av (int) är vad som kastar typen.,
statiskt skrivna språk
på statiskt skrivna språk som Rust en stor majoritet av värdeskapande och tilldelning kommer att ha uttryckliga typ anteckning krav med ett undantag för var kompilatorn kan dra slutsatsen typen. Följande är ett exempel som visar explicita och implicita typer i rost.
fn add_one(input: u8) -> u8 { input + 1}let four = add_one(3);
här är metodenadd_one explicit om ingångstypen och utgångstypen., Numret1 som läggs till här görs implicit ettu8 – nummer vid sammanställningstiden, eftersom sammanhanget hjälper till att dra slutsatsen typen och tillägget föru8 implementeras endast för att arbeta medu8 – nummer. Den sista raden skrivs implicit för att vara en u8 eftersom metoden själv definierar vilken typ som ska returneras.
vad som kan härledas i rost är ganska imponerande med användning av generika. Men användningen av inferens är begränsad till saker som kan vara kända vid sammanställningen., Om det inte går att känna till vid kompilering måste du uttryckligen definiera typen när som helst vid tilldelning. Ta följande metoddefinition:
use std::ops::Add;fn add_both<T: Add>(a: T, b: T) -> T::Output { a + b}
HärT kan vara vilken typ som helst som implementerar egenskapenAdd. TypenT::Outputdefinieras när tillägget är definierat för din specifika typ och är i allmänhet samma typ som T själv i det här fallet. Nu om vi ger två siffror som parametrar kompilatorn kommer att dra slutsatsen att typen till 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 jag kör ovanstående kod x anses vara typen i32. Exempleny ochz kräver att ingångsparametertyperna ska vara kända när de tillhandahålls till funktionen som inferens förT::Output är inte nödvändigtvis samma som Vad T kan härledas till som. Det skulle vara standard till i32 och sedan tilldela en i32 som en u8 eller u32 är helt enkelt fel.,
dynamiskt skrivna språk
nu med dynamiskt skrivna språk, måste du oroa dig mindre om typer, i sig, och mer om implicita eller explicita objekt eller beteende. Modellering kod runt objekt som har samma beteende är vad som kallas anka typing som är en högre domän att tänka i objektorienterad programmering där hantering av dessa objekt är implicit. Medan modellering av koden runt specifika objektklasser är ungefär som att använda explicit eller implicit typning., Men när du accepterar någon form av objekt som inmatning, måste koden i det avsnittet antingen hantera olika objekt uttryckligen eller lämna det ansvaret på annat håll.
för förtydligande, när du skriver kod för att hantera olika typer av saker, skriver du explicit kod. Men när samma kod redan har skrivits och du återanvänder den med ett enkelt metodanrop, är beteendet i det nya sammanhanget då implicit. Implicit är saker som görs som om automatiskt och hanteras utanför din nuvarande omfattning.,
i Ruby har de flesta typerna en design för explicit eller implicit konvertering. Tanken är att de implicita konverteringsmetoderna ska användas i implicita sammanhang och de explicita konverteringarna är avsedda för utvecklare att skriva inline i mycket mer sammanhang. Låt mig visa detta genom exempel.
# explicit"4".to_i + "5".to_i# => 9# implicitclass Seven def to_int 7 endendArray.new(Seven.new)# =>
här gör det uttryckliga exemplet det mycket uppenbart för läsaren att vi konverterarString objekt till ettInteger – objekt och utför tillägg mellan de två., Och det implicita exemplet är inte så uppenbart för läsaren som Array.new – metoden kallar implicit to_int-metoden på vilken parameter den ges. Heltalsklassen har metoden to_int definierad på varje instans av den som helt enkelt återvänder själv. Om du skriver42.to_int kommer du helt enkelt tillbaka42. Denna användning av att använda implicit konvertering som ett inmatningsskydd för metodanrop är en bra design för typsäkerhet genom design. Så här händer det om du ger det fel typ av objekt som inmatning som inte definierar to_int.,
Array.new("32")# TypeError (no implicit conversion of String into Integer)
det misslyckas inte bara, utan det ger oss ett användbart meddelande om att en implicit konvertering försökte och berättar vilken objektklass som gavs och vilken objektklass den förväntar sig. Implicita konverteringsmetoder i Ruby är ett sätt att säga detta objekt är verkligen vad du förväntar dig. Och explicit konvertering gör helt enkelt omvandlingen till den typ som förväntas.
Ruby har implicita och explicita alternativ för många av dess kärnobjekt.,
Ruby har också några klasser med klassmetoder som antingen kommer att göra en implicit konvertering eller returnera noll och det metodnamnet är try_convert.
Vi kan följa Ruby exempel med Array.new och ha en bra vakt för den typ av ingångsparametrar vi får genom att utforma implicita omvandlingar för våra egna anpassade typer. I det här exemplet, eftersom to_f är en explicit konvertering till ett Floatnummer i Ruby använder vi as_ som prefix istället för to_., Här är ett grundläggande exempel på implicit som ett mönster för säkerhet.
Nu kommer det att hjälpa andra utvecklare som använder klassen Bar att inte skicka den som en inkompatibel parameter. Det följer en konvention inom Ruby språket och bör vara mycket lättare för utvecklare att förstå med mer användbara fel. När du har andra objekt som du vill konvertera till ett Foo-objekt kan du definiera enas_f metod på den för en explicit konvertering och utvecklaren som använder det nya objektet kommer att vara explicit i dess användningBar.new(Baz.new.as_f)., Detta säkerställer att koden fungerar så mycket somBar ochFoo redan fungerar.
sammanfattning
handlingen av implicit och explicit kodning, och implicit och explicit kod, definieras i samband med utförande av ytterligare beteende eller typinställning / gjutning. Specifikt definieras implicita eller explicita metoder av de sammanhang där de är avsedda att användas. Implicit kod kan vara en mycket trevlig upplevelse om saker är väl namngivna eftersom det håller saker enkelt.,
men implicit kod, kod gör saker bakom kulisserna för dig, kan också vara ett svårt problem att lösa när gjort fel. Explicit kod gör koden tydlig när man tittar på det som detaljerna i vad som görs redan anges innan du och du behöver inte spåra frågor någon annanstans, men i allmänhet innebär mycket mer arbete skriva det. På egen hand kan det bli överväldigande så att hitta en ordentlig balans mellan de två är ofta den bästa lösningen. Var tydlig när du måste, och implicit när design och namngivning begrepp är lätta att förstå., Det kommer att göra för en bekvämare utvecklingserfarenhet.