som nybörjare i någonting är det viktigt att inte bara öva vad du än börjar på, utan också studera arbetet hos människor som är mer avancerade inom området. Som någon relativt ny för programmering gillar jag att läsa kod från programmerare på vilken nivå som helst, bara för att upptäcka olika tillvägagångssätt för liknande problem.

en skarp skillnad som jag märkte mellan min kod och koden för mer avancerade programmerare är filstruktur och antalet filer, men om du vill sätta en etikett på den, övade de separering av problem, och det var jag inte. jag visste att detta var ett viktigt begrepp i datorprogrammering, men för att vara ärlig, det som trippade mig mest i att öva SoC är att jag bara inte var bekväm med att använda Load, Require och Include — aka, de saker som länkar filer i ditt program tillsammans och gör SoC så mycket lättare att implementera.

Låt oss ta en titt bakom kulisserna på dessa tre metoder och hur de kan ta dina program till nästa nivå.

inkludera

den här är ganska enkel. Om du har skrivit flera klasser som delar liknande metoder kan du extrahera dessa metoder till en modul. När metoderna har skrivits in i modulen kan du ”inkludera” den modulen i någon av de klasser som kan behöva anropa dessa metoder. Inget behov av att hålla dessa metoder hängande runt. Nedan följer ett kort exempel på hur du skulle skriva ut det:

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

nu har båda klasserna tillgång till ice_cream metod genom användning av include .

ladda

medan includevisar hur vi kan använda Använd funktionalitet från en annan Ruby-klass, låt oss se hurload har en liknande funktionalitet, bara Istället för att ange klasser, specificerar vi filer från vår projektkatalog. Detta, och vår nästa metod, require, gör det möjligt för ett program att ha en Separation av problem med bara några extra rader högst upp i dina filer.

grundtanken med SoC är att koka ner en aspekt av ditt program så att det verkligen bara gör en sak. Vi gör detta när vi refactor kodar så att våra metoder och funktioner bara gör en sak. Detsamma gäller för våra filer.

saken att komma ihåg med load är att filen du skickar in faktiskt kommer att laddas varje gång den kallas. Så, om du har ett bibliotek med funktionalitet som du hoppas kunna använda, Kom ihåg att varje gång den beroende filen kallas filen skickas till load är också, väl, laddad. Om en fil i din app/program av någon anledning förändras dynamiskt och används som ett beroende av andra filer, bör du överväga att använda load . Annars kan load ha negativa effekter på appens prestanda på grund av antalet gånger filen laddas.

Kräv

Kräv är mycket som load , men den största skillnaden är att Kräv bara laddar den passerade filen en gång och kom ihåg att filen har laddats. Av denna anledning är require det mer populära alternativet när du använder tredjepartsbibliotek i ditt program eller program. Vänta lite, tredjepartsbibliotek? De låter som … pärlor! Det stämmer! När du har installerat en pärla i din katalog eller anger den i din Gemfile behöver du bara ”kräva” den pärlan högst upp i filen med den pärlens funktionalitet. Det är en bit av kakan.

Nu vet jag require kanske låter som lite Ruby magi, så låt oss gräva unsung hjälten i allt detta: $LOAD_PATH.

$LOAD_PATH är en global variabel som kommer med Ruby. Om du laddar IRB från din terminal och skriver in $LOAD_PATH får du något som liknar detta:

det är bara en rad absoluta vägar. Och när du installerar en pärla lägger Ruby till de absoluta sökvägarna för dessa gem-bibliotek till ditt $LOAD_PATH. Det är mer meningsfullt rätt? Ruby kan helt enkelt ringa funktionaliteten require begär eftersom den redan har den absoluta sökvägen för att få den lagrad i $LOAD_PATH .

jag hoppades att använda det här inlägget som ett sätt att utforska mer av varför vi skulle använda dessa metoder och hur de hjälper oss att bli bättre utvecklare. Om du är intresserad av mer av ”hur” dessa metoder fungerar, kan ytterligare forskning vara… krävs.