som nybegynder i noget er det vigtigt ikke bare at øve, hvad det er, du måske starter på, men også at studere arbejdet hos mennesker, der er mere avancerede i marken. Som en relativt ny til programmering kan jeg godt lide at læse kode fra programmører på ethvert niveau, bare for at opdage forskellige tilgange til lignende problemer.

en skarp forskel, jeg bemærkede mellem min kode og koden for mere avancerede programmører, er filstruktur og antallet af filer, men hvis du vil sætte en etiket på det, praktiserede de adskillelse af bekymringer, og det var jeg ikke. jeg vidste, at dette var et vigtigt koncept i computerprogrammering, men for at være ærlig er det, der snubler mig mest i at øve SoC, at jeg bare ikke var komfortabel med at bruge belastning, kræve og inkludere — aka, de ting, der forbinder filer i dit program sammen, og gør SoC så meget lettere at implementere.

lad os tage et kig bag kulisserne på disse tre metoder, og hvordan de kan tage dine programmer til det næste niveau.

Inkluder

Denne er ret ligetil. Hvis du har skrevet flere klasser, der deler lignende metoder, kan du udtrække disse metoder i et modul. Når metoderne er skrevet ind i modulet, kan du “inkludere” det modul i nogen af de klasser, der muligvis skal kalde på disse metoder. Ingen grund til at holde disse metoder hængende. Nedenfor er et kort eksempel på, hvordan du ville skrive det ud:

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

nu har begge klasser adgang tilice_creammetode ved brug afinclude.

Load

mensinclude demonstrerer, hvordan vi kan bruge brugsfunktionalitet fra en anden Ruby-klasse, lad os se, hvordanload har en lignende funktionalitet, kun i stedet for at specificere klasser, specificerer vi filer fra vores projektmappe. Dette og vores næste metode, require , gør det muligt for et program at have en adskillelse af bekymringer med blot et par ekstra linjer øverst i din fil(er).

den grundlæggende ide med SoC er at koge ned et aspekt af dit program, så det virkelig kun gør en ting. Vi gør dette, når vi refactor kode, så vores metoder og funktioner kun gør en ting. Det samme gælder for vores filer.

den ting at huske med load er, at den fil, du sender ind, faktisk vil blive indlæst hver gang den kaldes. Så hvis du har et bibliotek med funktionalitet, du håber at bruge, skal du huske, at hver gang den afhængige fil kaldes, sendes filen til load er også godt indlæst. Hvis en fil i din app/program af en eller anden grund ændrer sig dynamisk og bruges som afhængighed af andre filer, bør du overveje at bruge load . Ellers load kan have negative virkninger på din apps ydeevne på grund af antallet af gange filen er indlæst.

Kræv

Kræv er meget somload , men den største forskel er, at Kræv kun indlæser den overførte fil en gang, og husk derefter, at filen er indlæst. Af denne grund er require den mere populære mulighed, når du bruger tredjepartsbiblioteker i dit program eller Program. Vent et øjeblik, tredjeparts biblioteker? Det lyder som … perler! Det er rigtigt! Når du har installeret en perle i din mappe eller angivet den i din Gemfile, behøver du kun at “kræve” den perle øverst i filen ved hjælp af perlens funktionalitet. Det er et stykke kage.

nu ved jegrequirelyder måske som en smule Rubinmagi, så lad os grave den ubesungne helt i alt dette:$LOAD_PATH.

$LOAD_PATH er en global variabel, der kommer med Ruby. Hvis du indlæser IRB fra din terminal og skriver $LOAD_PATH , får du noget, der ligner dette:

det er bare en række absolutte stier. Og når du installerer en perle, tilføjer Ruby de absolutte stier for disse perlebiblioteker til din $LOAD_PATH. Det giver mere mening rigtigt? Ruby kan simpelthen kalde funktionaliteten require anmoder om, da den allerede har den absolutte sti for at få den gemt i $LOAD_PATH .

Jeg håbede at bruge dette indlæg som et middel til at udforske mere af, hvorfor vi ville bruge disse metoder, og hvordan de hjælper os med at blive bedre udviklere. Hvis du er interesseret i mere af “hvordan” disse metoder fungerer, kan yderligere forskning være… påkrævet.