Hva er tidlig og sen binding?
On november 18, 2020 by adminJeg hører stadig om tidlig og sen binding, men jeg forstår ikke hva de er. Jeg fant følgende forklaring som jeg ikke forstår:
Tidlig binding refererer til tildeling av verdier til variabler i løpet av designtiden, mens sen binding refererer til tildeling av verdier til variabler i løpetid.
Kan noen definere de to typer binding og sammenligne dem?
Kommentarer
- kompileringstid vs kjøretid.
- Her er en god lesing om emnet: no.wikibooks.org/ wiki / Introduction_to_Programming_Languages / …
Svar
Det er to hovedkonsepter i forvirring: binding og lasting. Det er sammensatt av begrepet DataBinding, som er et sted i midten som ofte gjør begge deler. Etter å ha vurdert det, skal jeg legge til et konsept til, for å fullføre trifecta, utsendelse.
Typer
Sen binding : type er ukjent til variabelen utøves i løpetid; vanligvis gjennom oppdrag, men det er andre måter å tvinge en type på; dynamisk skrevne språk kaller dette en underliggende funksjon, men mange statisk skrevne språk har noen metode for å oppnå sen binding
Implementert ofte ved hjelp av [spesielle] dynamiske typer, introspeksjon / refleksjon, flagg og kompilatoralternativer, eller gjennom virtuelle metoder ved å låne og utvide dynamisk utsendelse
Early Binding : type er kjent før variabelen utøves i løpetid, vanligvis gjennom en statisk, deklarativ måte
Implementert ofte ved bruk av standard primitive typer
Funksjoner
Statisk utsendelse : kjent, spesifikk funksjon eller subrutine ved kompileringstid; det er entydig og matches av signaturen
Implementert som statiske funksjoner; ingen metode kan ha samme signatur
Dynamic Dispatch : ikke en spesifikk funksjon eller subrutine ved kompileringstidspunktet; bestemmes av konteksten under utførelsen. Det er to forskjellige tilnærminger til «dynamisk utsendelse», preget av hvilken kontekstuell informasjon som brukes til å velge riktig funksjon implementering.
I singel [ dynamisk ] utsendelse , bare typen forekomst blir brukt for å bestemme riktig funksjonsimplementering. I statisk typede språk betyr dette i praksis at forekomststypen bestemmer hvilken metodeimplementering som skal brukes uavhengig av referansetypen som er angitt når variabelen deklareres / tildeles. Fordi bare en enkelt type – typen objektforekomst – brukes for å utlede riktig implementering, kalles denne tilnærmingen «single dispatch».
Det er også multiple [ dynamic ] utsendelse , der inputparametertyper også hjelper til med å bestemme hvilken funksjonsimplementering du skal ringe. Fordi flere typer – både typen forekomst og typen (e) av parameteren (e) – påvirker hvilken metodeimplementering som er valgt, kalles denne tilnærmingen «multiple dispatch».
Implementert som virtuelle eller abstrakte funksjoner; andre ledetråder inkluderer overstyrte, skjulte eller skyggelagte metoder.
NB: Hvorvidt metodeoverbelastning innebærer dynamisk utsendelse er språkspesifikk. For eksempel sendes overbelastede metoder i Java statisk.
Verdier
Lazy Loading : strategi for objektinitialisering som definerer verditildeling til nødvendig ; tillater at et objekt er i en vesentlig gyldig, men bevisst ufullstendig tilstand og venter til dataene er nødvendige før de lastes inn; ofte funnet spesielt nyttig for å laste inn store datasett eller vente på eksterne ressurser
Implementert ofte ved ikke målrettet å laste inn en samling eller en liste i et sammensatt objekt under konstruktøren eller initialiseringssamtalene til noen nedstrøms innringer ber om å se innholdet i den samlingen (f.eks. get_value_at, get_all_as, etc).Variasjoner inkluderer innlasting av metainformasjon om samlingen (som størrelse eller nøkler), men utelatelse av de faktiske dataene; gir også en mekanisme for noen driftstider for å gi utviklere et ganske trygt og effektivt implementeringsskjema for singleton
Ivrig lasting : strategi for objektinitialisering som umiddelbart utfører alle verditildelinger for å ha alle dataene som trengs for å være komplette før de vurderer å være i en gyldig tilstand.
Implementert ofte av gi en sammensatt gjenstand med alle sine kjente data så snart som mulig, som under en konstruktøranrop eller initialisering
Data Binding : innebærer ofte å opprette en aktiv lenke eller kart mellom to kompatible informasjonsstrømmer slik at endringer til den ene reflekteres tilbake i den andre og omvendt; For å være kompatible må de ofte ha en felles basetype, eller grensesnitt
Implementert ofte som et forsøk på å gi renere, konsistent synkronisering mellom forskjellige applikasjonsaspekter (f.eks. visningsmodell å se, modell til kontroller osv.) og snakker om begreper som kilde og mål, endepunkter, bind / bind opp, oppdatering og hendelser som on_bind, on_property_change, on_explicit, on_out_of_scope
EDIT NOTE: Siste store redigering for å gi beskrivelse av eksempler på hvordan disse ofte oppstår. Spesielle kodeeksempler avhenger helt av implementeringen / kjøretiden / plattformen
Kommentarer
- Dette svaret virker for spesifikt for objektorienterte språk.
- @Jack Jeg har ikke ‘ Jeg føler ikke det slik, jeg synes dette er et utmerket som dekker mange aspekter.
Svar
Alt som avgjøres av kompilatoren mens du kompilerer, kan refereres til TIDLIG / KOMPILERTID Binding og alt som skal avgjøres på RUNTIME kalles LATE / RUNTIME binding.
For eksempel,
Metode Overbelastning og metode Overstyring .
1 ) I Metodeoverbelastning metoden din kaller metodene ar avgjøres av kompilatoren i den forstand at hvilken funksjon som skal kalles avgjøres av kompilatoren din på kompileringstidspunktet. Derfor er det TIDLIG BINDING .
2) I metode Overstyring avgjøres det ved RUNTIME hvilken metode som er kommer til å bli kalt. Så det er referert til som SEN BINDING .
Forsøkt å holde det enkelt og lett å få. Håper dette hjelper.
Svar
Sen binding er når atferd vurderes ved kjøretid. Det er nødvendig når du virkelig vil bestemme hvordan du skal handle ut fra informasjon du bare har når programmet kjører. Det klareste eksemplet er etter min mening den virtuelle funksjonsmekanismen, spesielt i C ++.
class A { public: void f() {} virtual void g() {} }; class B : public A { void f() {} virtual void g() {} }; int main() { A* a = new B; a->f(); a->g(); }
I dette eksemplet vil a->f()
faktisk kalle void A::f()
, fordi det er tidlig (eller statisk ) bundet, og slik at programmet ved kjøretid tenker det bare er en peker til en A
type variabel, mens a->g()
vil faktisk ringe void B::g()
, fordi kompilatoren ser g()
er virtuell, og injiserer kode for å slå opp adressen til riktig funksjon for å ringe ved kjøretid.
Kommentarer
- » Kjøretiden «? Du ‘ snakker om C ++. C ++ kompilerer rett til maskinkode, det trenger ikke ‘ ikke en kjøretid for å løse virtuelle metoder.
- @tdammers C ++ trenger faktisk et kjøretidsbibliotek, men ikke for virtuelle samtaler. Hvis du leser nøye, vil du ‘ legge merke til at dette svaret sier at kompilatoren » injiserer kode for å slå opp adressen til riktig funksjon [ …] ved kjøretid «.
- Vel, men den » -koden å slå opp adressen til riktig funksjon » er i utgangspunktet bare en type agnostisk to-trinns pekereferanse etterfulgt av en funksjonsanrop. Det er ingen » tenkning » involvert; den eneste grunnen til at det fungerer pålitelig er at kompilatoren utfører typen kontroll på kompileringstidspunktet ; ved kjøretid stoler den genererte koden på at kompilatoren har utført typekontroll lekser. Hvis du bruker usikre rollebesetninger (f.eks.C-stil pekere kaster), kan du lovlig behandle C ++ objekter som objekt av feil klasse, men vtabellene deres blir ødelagt og koden bryter bare.
- @tdammers Jeg prøvde å holde meg borte fra den slags svar, fordi det ‘ er en implementeringsdetalj av kompilatorer, som kanskje eller ikke kan være sant for noen esoteriske kompilatorer. Det som betyr noe er konseptet.
- @tdammers Og med » kjøretiden » mener jeg » programmet ved kjøretid «. Åpenbart er C ++ ikke ‘ t administrert. Men siden du viste meg, kan det føre til forvirring, jeg ‘ Jeg endrer den til den fulle ordlyden.
Svar
hvis du er kjent med funksjonspekere, vil dette være et eksempel. Funksjoner som er definert kan sies å være tidlig binding. mens hvis du bruker Funksjonspekere, er det sen innbinding.
int add(int x,int y) { return x+y; } int sub(int x,int y) { return x-y; } int main() { //get user choice int(*fp)(int,int); //if add fp=add; //else if sub fp=sub; cout<<fp(2,2); }
her funksjoner legger til og sub er funksjoner (adressen er bundet ved kompilering av tidskobler)
men funksjonspekeren er sen binding av fp kan ringe enten add eller sub avhengig av brukervalg [ved kjøretid].
Svar
Bare tidlig og sen binding gi mening i sammenheng med typer og ikke slik du beskriver det. Nesten alle moderne språk er skrevet i den forstand at alle verdier har faste typer. Forskjellen kommer inn når vi ser på dynamisk vs statisk typede språk. I dynamisk typte språk har variabler ikke typer slik at de kan referere til verdier av hvilken som helst type, og dette betyr at når du kaller en metode på et objekt som det refereres til av en eller annen variabel, er den eneste måten å avgjøre om det anropet er gyldig slå opp klassen for objektet og se om den metoden faktisk eksisterer. Dette gir noen kule ting som å legge til nye metoder i klasser på kjøretid fordi den faktiske metoden oppslag er utsatt til siste øyeblikk. De fleste kaller denne tilstanden saker sent bindende.
I et statisk skrevet språk har variabler typer, og når de er erklært, kan de ikke referere til noen verdi som ikke er av samme type. Dette er ikke sant, men la oss anta det for nå. Nå hvis du vet at variabelen bare vil referere til verdier av en bestemt type, er det ingen grunn til å finne ut om et metodeanrop er gyldig eller ikke på kjøretid, fordi du kan bestemme gyldigheten før koden noen gang kjøres. Dette blir referert til som tidlig binding.
Et eksempel på å demonstrere sen binding i rubin:
a = 1 # a is an integer at this point a.succ # asking for its successor is valid class A def method_a # some code end end a = A.new a.method_a # this is also valid a.succ # this is not valid class A # we can re-open the class and add a method def succ # some more code end end a.succ # now this is valid
Ovennevnte handlingsrekkefølge er ikke mulig på et språk som Java der alle typer er løst på kjøretid.
Svar
I stedet for å gi deg en akademisk definisjon I vil prøve å vise deg noen av forskjellene ved hjelp av et eksempel fra den virkelige verden ved hjelp av VBA:
Tidlig binding:
Dim x As FileSystemObject Set x = New FileSystemObject Debug.Print x.GetSpecialFolder(0)
Dette krever at det settes en referanse til «Microsoft Scripting Runtime» -komponenten ved designtid . Det har fordelen at du får en feilmelding allerede ved kompileringstidspunktet når du har en skrivefeil i FileSystemObject
eller metodenavn som GetSpecialFolder
.
Sen binding
Dim x As Object Set x = CreateObject("Scripting.FileSystemObject") Debug.Print x.GetSpecialFolder(0)
Dette krever ikke at det skal angis en referanse på forhånd, forekomsten opprettes og typen besluttsomhet vil bare skje i løpetid. Kompilatoren klager ikke på kompileringstidspunktet når du prøver å kalle en ikke-eksisterende metode for x
, dette vil bare føre til en kjøretidsfeil når den spesifikke linjen utføres .
Så ulempen med sen binding er at du ikke har noen sterk type som sjekker her. Men det er også fordelen – la oss si at du har en komponent der det finnes flere versjoner, og hver nyere versjon gir noen tilleggsfunksjoner. (Et virkelig eksempel er MS Office-komponenter, som Excel COM-grensesnittet) Sen binding tillater du skriver kode som fungerer sammen med alle versjonene – du kan først bestemme den spesifikke komponentversjonen, og hvis du finner ut at du bare har en eldre versjon tilgjengelig, må du unngå å utføre funksjonssamtaler som ikke fungerer med den versjonen.
Svar
Det vanligste eksemplet på sen binding er kanskje å løse nettadresser. Den støtter dynamiske systemer og store systemer uten å prøve å koble til og binde hvert nettsted i verden før du kan nå noen, men på den annen side medfører det noe overhead (DNS-oppslag, mye mindre IP-ruting) ved kjøretid.
På det lyset er de fleste varianter av binding i språkmiljøer mer eller mindre tidlig, på kompileringstidspunkt eller lenketid.
Hver type har kostnader og fordeler.
Kommentarer
- Kan du lage en referanse for denne definisjonen av binding?Jeg har ikke hørt om å løse internettadresser som » binding «, selv om binding er handlingen med å løse navn, antar jeg at noen har argumentert at begrepet tidlig / sen binding kan brukes på å løse URI til internettadresser. Men dette er ikke en vanlig tolkning, og begrepet tidlig / sen binding er forut for tiden der datamaskiner ofte var koblet til internett.
Legg igjen en kommentar