Objektorienteret programmering blev det dominerende programmeringsparadigme i 90'erne, og dets principper forbliver ekstremt værdifulde og bredt vedtaget af flere programmeringssprog (f.eks. Python, Java, TypeScript osv.). Hvis du programmerer, må du have mødt det allerede på din vej.
Konceptet er meget simpelt: forvandle alt, hvad du har brug for at arbejde med, til et objekt. Derefter er det op til dig, hvor mange og hvilken slags objekter du opretter. I dag vil jeg dele med dig, hvad jeg lærte om at adskille apparkitektur i objekter, startende med en hurtig introduktion til objektorienteret programmering (OOP).
Det er et programmeringsparadigme, der strukturerer et softwareprogram i henhold til objekter. Kort sagt, det opretter objekter, der indeholder funktioner og data. Dette paradigme er stærkt afhængig af begrebet klasser og objekter.
Med andre ord, i et OOP-sprog skrives kode for at definere klasserne og de respektive objekter ved at følge fire principper: indkapsling, abstraktion, arv og polymorfisme.
Søg andre steder på nettet, og du vil hurtigt finde en liste over principper, der er knyttet til OOP. Disse er: indkapsling, abstraktion, arv og polymorfisme. Lad os se, hvad disse principper faktisk betyder:
Det er dog ikke her, jeg vil fokusere på denne artikel. I det mindste ikke på den mere lærde version af de objektorienterede programmeringsprincipper. Her finder du mere praktisk viden om objektorienteret programmering og reel indsigt i, hvordan man forbedrer sig inden for kunsten at forvandle alt til et objekt. I slutningen af denne artikel vil det være helt klart, hvorfor det er relevant for alle, der programmerer derude.
I min programmeringserfaring vil jeg altid huske den dag, hvor jeg åbnede et af de store projekter, og mængden af filer i det var simpelthen overvældende. Det er da jeg tænkte: dette er umuligt at forstå. Konceptet med at omdanne en simpel idé til en enorm mængde filer virker som en overkill, men meget ofte er det ikke.
For mig er det spørgsmål, jeg stiller mig selv mest, når jeg designer app-arkitektur, „skal jeg oprette et objekt til det?“ Og det meste af tiden er svaret ganske enkelt:
Ja, det burde jeg.
I sidste ende, det er meget lettere at læse 10 filer med forskellige objekter med navne, der repræsenterer deres funktion end 1 stor bunke kode der gør alt. Det eneste problem her er at organisere den store mængde filer, du opretter, i en struktur, der kan være let at forstå og søge igennem efter alle, der kan hente dit arbejde senere.
Som en iOS udvikler, Jeg følger, hvad de fleste iOS-udviklere bruger, hvilket er MVC model, og jeg forsøger altid at organisere filer i mapper I stedet for bare at smide dem alle sammen ét sted.
I stedet for at oprette en klasse og give den et sæt egenskaber og enumtyper, der skal konfigureres, så tænk, om det ikke ville være bedre bare at adskille dem i elegante underklasser for lettere identifikation af hvad de rent faktisk gør, hvilket efterlader basen en generisk nok til at fortsætte med at skalere den senere.
En af skønhederne ved objektorienteret programmering er, at klasserne for objekter, du opretter, kan genbruges i andre projekter, hvilket er en enorm tidsbesparelse. Tænk over det, når du opretter objekter og gør dem generiske. Underklassingsmetoden kan helt sikkert hjælpe dig med at gøre det.
Det er bedre at adskille klassen for at styre API-opkald eller i appkøb til den generiske, som du kan bruge på tværs af dine projekter og underklasse med en bestemt, der henter dig de data, du har brug for.
Nogle gange er jeg nødt til at oprette en metode, der kræver, at mange egenskaber videregives. Jeg vil ikke bede om hver enkelt efter en, så jeg besluttede at lægge dem alle i en ordbog eller en matrix og videregive den.
Det virker praktisk nok, men det er det aldrig.
Jeg vender tilbage til det en måned senere, eller værre, en anden prøver at bruge det, og de har virkelig svært ved at sammensætte egenskaberne nøjagtigt som jeg gjorde, og måske endda bruge lidt tid på at fejlsøge, hvorfor en af dem opfattes som nul på deres vej.
I sidste ende, det er meget lettere at passere hele objektet hvoraf egenskaberne tilhører, selvom det har meget mere, end du har brug for. Denne løsning også skalerer bedre fordi du aldrig ved, hvornår du har brug for hele objektkonteksten, selvom du bare starter med en lille del af den.
Alle de programmeringssprog Jeg ved, at jeg er objektorienteret, og alligevel finder jeg stadig forskellige måder at besvare dette enkle spørgsmål på: hvilken slags objekter skal repræsentere dette? Mængden af muligheder kan udgøre en udfordring, når det kommer til objektorienteret programmering, men alternativet til ikke at bruge er hverken levedygtigt eller ønskeligt.
Det objektorienterede programmeringsparadigme fokuserer på objekter og om, hvordan disse objekter interagerer. Det kræver, at udvikleren planlægger kodningen på forhånd, hvilket fører til bedre datastruktur og muliggør genanvendelighed.
Dette paradigme indebærer fire hovedprincipper (indkapsling, arv, polymorfisme og abstraktion), der skal følges, når man udvikler en objektorienteret software.
Når OOP implementeres, vil nogle af bedste anbefalinger udviklere kan ansøge er:
1. Opret så mange klasser som nødvendigt;
2. Brug flere underklasser;
3. Gør objekter mere generiske;
4. Riv ikke genstande fra hinanden.
En senior iOS-udvikler, der er en del af et fleksibelt iOS-team og giver enkeltpersoner mulighed for at nå deres drømme og mål.
Marketing praktikant med særlig interesse for teknologi og forskning. I min fritid spiller jeg volleyball og forkæler min hund så meget som muligt.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
