Som nybegynner i noe, er det viktig ikke bare å øve hva det er du kan starte ut på, men å også studere arbeidet til folk mer avanserte i feltet. Som noen relativt ny til programmering, jeg liker å lese kode fra programmerere på alle nivå, bare for å oppdage ulike tilnærminger til lignende problemer.

En grell forskjell jeg la merke til mellom koden min og koden til mer avanserte programmerere er filstruktur og antall filer, men hvis du vil sette en etikett på Det, praktiserte De Separasjon Av Bekymringer, og det var jeg ikke. jeg visste at dette var et viktig konsept i dataprogrammering, men for å være ærlig, er det som tripper meg mest i å praktisere SoC at jeg bare ikke var komfortabel med Å Bruke Last, Krever Og Inkludere-aka, de tingene som knytter filer i programmet sammen, og gjør SoC så mye enklere å implementere.

La oss ta en titt bak kulissene på disse tre metodene og hvordan de kan ta programmene dine til neste nivå.

Inkluder

denne er ganske grei. Hvis du har skrevet flere klasser som deler lignende metoder, kan du trekke ut disse metodene i En Modul. Når metodene er skrevet inn i modulen, kan du «inkludere» den modulen i noen av klassene som kanskje må ringe på disse metodene. Du trenger ikke å holde disse metodene hengende rundt. Nedenfor er et kort eksempel på hvordan du vil skrive det ut:

class Chocolate
include IceCream
endclass Vanilla
include IceCream
endmodule IceCream
def ice_cream
end
end

nå har begge klassene tilgang til ice_cream metoden gjennom bruk av include.

Load

Mens include demonstrerer hvordan vi kan bruke bruksfunksjonalitet fra en Annen Ruby-klasse, la oss se hvordan load har en lignende funksjonalitet, bare i stedet for å spesifisere klasser, spesifiserer vi filer fra prosjektkatalogen vår. Dette, og vår neste metode, require, aktiverer et program for Å Ha En Separasjon Av Bekymringer med bare noen få ekstra linjer øverst i filen (e).Den grunnleggende ideen Med SoC er å koke ned et aspekt av programmet ditt slik at det egentlig bare gjør en ting. Vi gjør dette når vi refactor kode slik at våre metoder og funksjoner bare gjøre en ting. Det samme gjelder for våre filer.

tingen å huske med load er at filen du passerer i faktisk vil bli lastet hver gang den kalles. Så, hvis du har et bibliotek med funksjonalitet du håper å bruke, husk at hver gang den avhengige filen kalles filen sendt til load er også, vel, lastet. Hvis en fil i appen/programmet av en eller annen grunn endres dynamisk og brukes som avhengighet til andre filer, bør du vurdere å bruke load. Ellers kan load ha negative effekter på appens ytelse på grunn av antall ganger filen er lastet.

Require

Require er mye som load, men hovedforskjellen er at require bare vil laste den passerte filen en gang, og husk at filen er lastet. Av denne grunn er require det mest populære alternativet når du bruker tredjepartsbiblioteker i programmet eller programmet. Vent litt, tredjepartsbiblioteker? De høres ut som … perler! Det stemmer! Når du har installert en perle i katalogen din eller spesifiser den i Gemfile, trenger du bare å «kreve» den perlen øverst i filen ved hjelp av den perlen funksjonalitet. Det er et stykke kake.

nå vet jeg require kan høres ut som Litt Rubin magi, så la oss avdekke den ukjente helten i alt dette: $LOAD_PATH.

$LOAD_PATH er en global variabel som følger Med Ruby. Hvis DU laster IRB FRA terminalen din og skriver inn $LOAD_PATH , får du noe som ligner dette:

Det er bare en rekke absolutte baner. Og når Du installerer en perle, Legger Ruby de absolutte banene til disse perlebibliotekene til $LOAD_PATH. Det gir mer mening rett? Ruby kan bare ringe funksjonaliteten require ber om siden den allerede har den absolutte banen for å få den lagret i $LOAD_PATH.jeg håpet å bruke dette innlegget som et middel til å utforske mer av hvorfor vi ville bruke disse metodene og hvordan de hjelper oss å bli bedre utviklere. Hvis du er interessert i mer av «hvordan» disse metodene fungerer, kan ytterligere forskning være … nødvendig.