Tot nu toe hebben we een paar manieren geleerd om onze Python-code te organiseren.
Het eerste dat we goed deden, we hebben Python gewoon in een bestand geschreven en dat organiseert het.
Rechts?
Onze hele code heeft tot nu toe in één enkel bestand gestaan.
Dus dat was een manier waarop we onze code hebben georganiseerd.
Vervolgens leerden we over functies en werden functies gebruikt als een manier om geen code te schrijven die we
steeds opnieuw herhalen, we konden functies schrijven die we overal in ons bestand kunnen gebruiken, zodat we deze
functies steeds opnieuw kunnen aanroepen en we kunnen de functies de juiste naam geven, zodat onze code logisch
is.
En toen leerden we over klassen, schrijf deze blauwdrukken waaruit we objecten kunnen maken.
We kunnen nieuwe Python-gegevenstypen instantiëren die verder gaan dan degene die ze ons zojuist hebben gegeven.
Rechts.
In plaats van alleen woordenboeken en lijsten te hebben, kunnen we onze eigen gewoonte maken zodra onze eigen lijsten misschien
extra functies hebben.
En we kunnen klassen gebruiken om onze code te ordenen om ze in een doos te plaatsen en elke klasse een bepaalde methode en
attribuut te geven die het mooi verpakt voor ons om te gebruiken.
We hebben ook geleerd over functioneel programmeren en hoe we, in tegenstelling tot, laten we
zeggen, objectgeoriënteerd programmeren, waar we veel klassen zien met functioneel programmeren, we gewoon veel functies gebruiken,
veel pure functies.
En we hebben gegevens die we zojuist aan die functies hebben doorgegeven en we organiseren dingen in kleine stukjes.
Al deze dingen waren voor ons bedoeld om onze code schoon te houden, onze code beter onderhoudbaar te maken, en zo
onze code georganiseerd te houden, want naarmate we meer regels code schrijven, wordt het steeds moeilijker om alles in je hoofd
te houden.
Als andere mensen zich bij uw team voegen om aan uw project te werken, hebben ze een gemakkelijke manier nodig om erachter te komen hoe de
dingen werken.
Maar we hebben nog steeds een probleem, en dat probleem is dat alles in dit ene bestand zit, alle functies,
alle klassen die we hebben geschreven in slechts één dot pi-bestand staan.
Maar in het echte leven is dit niet het geval.
We hebben veel meer code en we kunnen niet slechts één bestand hebben met miljoenen regels code.
Dus hoe blijven we georganiseerd?
We zullen.
Als we meerdere bestanden van Python hadden.
Zo ook, want ons project wordt steeds groter.
Zou dit werken?
Is er een manier voor ons om al deze bestanden aan elkaar te koppelen?
In feite is er en dit is heel gebruikelijk in de hele industrie, en we noemen dit
de manier om codemodules te organiseren.
En modules zijn gewoon, nou ja, deze bestanden, elk van deze bestanden, elk dot py-bestand is een module.
En door deze modules te bouwen, zoals we verschillende functies hebben gebouwd, een beetje zoals we verschillende
klassen hebben gebouwd, want binnen deze bestanden kunnen we klassen hebben, we kunnen functies hebben, maar we kunnen ook
verschillende bestanden hebben.
Dus een laag hoger om onze code op te delen.
En in deze sectie gaan we alles leren over modules en proberen het onder de knie te krijgen en te zien
hoe we georganiseerde code kunnen schrijven.
Laten we eens kijken, je kunt hier zien, als ik op bestanden in onze Reppel klik, hebben we een hoofd-DCPI en
elke keer dat ik dit najaar op uitvoeren klik, ren ik.
Maar wat als we meer bestanden hebben?
Wat als ik hier nog een bestand toevoeg en we het utility dot pi noemen?
Dus op basis van wat ik je net heb verteld, zijn deze twee dingen waar ze goed voor zijn, de belangrijkste DCPI
is een module-hulpprogramma.
Tappy is een module.
En bij het schrijven van modules gebruiken we dezelfde principes als variabelen in Python, dat is snake case, dat wil zeggen,
als het spaties zijn, gebruiken we onderstrepingstekens, alles is een kleine letter.
Dus hoe verdelen we deze modules en dit komt met oefening als je net begint, het is moeilijk te zeggen, hé,
wat gaat waar in?
Wat komt in welk bestand?
Maar het is vergelijkbaar met lessen, toch?
Gelijk aan functies.
We willen onze code opdelen in begrijpelijke stukken.
Nogmaals, laten we zeggen dat we bij Netflix werken.
We hebben misschien een bestand speciaal voor de video's.
We hebben misschien een ander bestand of module gewijd aan de login van een gebruiker, misschien een ander bestand
gewijd aan analyses en het uitzoeken van aanbevelingen voor gebruikers.
We willen deze klassen en functies samen groeperen in een logisch bestand.
Een van de meest gebruikelijke manieren om een module te gebruiken, is zoiets als een hulpprogramma.
Laten we zeggen dat we een hulpprogramma-module willen maken die een module is die veel van een soort gereedschapsriem heeft,
zeer eenvoudige functies die we in ons hele project kunnen gebruiken, omdat we ons kunnen voorstellen dat we hier
meerdere bestanden hebben.
Laten we dus een heel eenvoudig voorbeeld maken.
Ik ga zeggen dat hier een vermenigvuldigingsfunctie bestaat.
En dit heeft naam één en nummer twee.
En hier gaan we Namwon Times verdoofd terugbrengen naar een heel eenvoudige functie en nogmaals, we zullen
ook een verdeelfunctie hebben.
En ja, dit is een beetje nutteloos omdat we gewoon de plus of de operand in Python kunnen gebruiken.
Maar blijf hier bij me en probeer je een voorbeeld te laten zien.
Oké, dus nummer twee, ik ga terug naar nummer één, gedeeld door nummer twee, mooi en eenvoudig.
Dus dit.
Is ons gebruiksmodel dat al deze functies voor ons heeft.
Merk nu op dat we eigenlijk niets doen in dit bestand.
Ik definieer gewoon functies, maar ik voer geen van de functies uit.
Maar laten we zeggen dat we deze hulpprogramma-module hebben en dat ik hem in mijn belangrijkste valkuil wil gebruiken.
Hoe zouden we dit gaan doen?
Welnu, de manier waarop we communiceren tussen deze twee bestanden is vrij eenvoudig, het enige dat we hoeven te doen is het
importcommando dat we importeren te gebruiken en het vervolgens de bestandsnaam te geven die we willen importeren.
Wat willen we importeren?
We willen het hulpprogramma zomaar importeren.
En merk op dat ik de punttaart niet toevoeg omdat we aannemen dat wat we ook gaan importeren een
python-bestand zal zijn.
Dat hoeven we dus niet te doen.
Alleen de naam, zomaar.
Laten we nu hier het hulpprogramma afdrukken.
Als ik dit uitvoer.
Wauw, zie je dat we een module-hulpprogramma hebben en dan is dit een bestandspad dat deze website voor ons genereert, dus het
maakt niet echt uit.
Er zijn hier een paar dingen gebeurd.
Een daarvan is dat we deze PAE-cachemap, underscore, underscore, PAE-cache hebben gegenereerd.
En oh, jongen, wat is dit voor gebrabbel?
Hmm, dit is nogal verwarrend, toch?
Nou, dit taartgeld wordt elke keer gecreëerd als we een dossier runnen met, laten we zeggen, goedkeuringen.
Dus als we modules gebruiken.
Zie je, wat Pae Cash doet, is wanneer we klikken, rennen.
De tolk gaat deze podcast-map maken en zegt, hey, ik voer dit bestand
uit.
Deze mag niets opslaan dat de invoer van bestanden niet kan betalen, laten we zeggen een hulpprogramma.
In ons geval ga ik het verzilveren.
Dus kijk hoe hier dot PC staat.
Dit komt omdat het de C Python-interpreter gebruikt.
Onthoud dat dit de C-python is, wat de interpreter is die is geschreven, en C, dus dit is eigenlijk een gecompileerd
bestand, zodat de volgende keer dat ik klik op uitvoeren hier op mijn hoofd-DCPI, er niets verandert, want wat er gaat gebeuren is
in plaats van het laden van het hulpprogramma Dopy, het gaat deze gecompileerde versie van het hulpprogramma laden omdat er
niets is veranderd en het hulpprogramma DCPI.
En dit maakte dingen sneller toen ik Maeng Pie opnieuw probeerde te gebruiken.
Dat is wat cachen is.
Caching is, hé, ik ga dit onthouden, en dit is de compileerversie, dus
ik hoef de compilatiestap niet opnieuw te doorlopen.
Maar merk op dat het hoofdbestand niet wordt gecompileerd omdat we het elke keer uitvoeren.
Als we nu de hulpprogramma-functie wijzigen zodat de splitsing daar niet is, klik ik op uitvoeren en je merkt het
hier niet.
Maar dit is nu opnieuw uitgevoerd omdat we een ander bestand hebben.
Je ziet dat we hier vermenigvuldigen, maar niet delen.
Dus laten we de kloof weer terugbrengen.
Ga terug naar hier, klik, ren.
En daar ga je, we hebben hier nu een scheiding tussen twee, maar dit is iets dat we niet aanraken.
Dit komt gewoon onder de motorkap met elke editor die we gebruiken.
En in een paar video's laten we je zien hoe dit ook gebeurt als je zoiets als een cirkeldiagram
gebruikt.
Dit is gewoon iets dat editors ons toestaan om te doen, zodat onze programma's sneller kunnen werken.
Dus ik heb nu toegang.
Laten we dit een beetje kleiner maken.
Ik heb nu toegang tot het hulpprogramma.
En hier is het interessante deel.
Als ik hier een punt zet, kijk daar dan naar.
Ik heb toegang tot delen en vermenigvuldigen, zodat ik getallen kan vermenigvuldigen.
Laten we zeggen twee en drie.
Klik op uitvoeren.
En ik kan de hulpprogramma-module in mijn hoofdbestand gebruiken, heel, heel cool als ik deel en ik klik op uitvoeren.
Deze kan ik ook gebruiken.
Heel, heel cool, en ik kan zo vaak importeren als ik wil als ik hier een ander bestand had en ik wil nog
iets importeren, laten we zeggen dat er een hulpprogramma is om te archiveren.
Nou, ik kan dat importeren en zoveel dingen importeren als ik wil en ze in mijn bestanden gebruiken.
Hoe cool is dat?
Dus nu hebben we een manier om onze code te organiseren en al deze bestanden met elkaar te laten communiceren, omdat
we in het echte leven grote projecten hebben en aan deze grote projecten zal worden gewerkt door verschillende
teams, verschillende programmeurs.
En we hebben een manier nodig om met al deze bestanden te werken.
En door de importinstructies tussen modules te gebruiken, kunnen we functionaliteit gebruiken net zoals we de
functionaliteit konden gebruiken die functies ons tussen verschillende bestanden gaven.
En als je bij een bedrijf werkt, zijn de eerste paar regels van een dot
pi-bestand meestal importinstructies, omdat je meestal met andere bestanden communiceert.
Laten we wat meer leren in de volgende video.