Objektorienterad programmering blev det dominerande programmeringsparadigmet på 90-talet, och dess principer förblir extremt värdefulla och allmänt antagna av flera programmeringsspråk (t.ex. Python, Java, TypeScript, etc.). Om du programmerar måste du ha mött det redan på din väg.
Konceptet är mycket enkelt: förvandla allt du behöver för att arbeta med till ett objekt. Sedan är det upp till dig hur många och vilken typ av objekt du skapar. Idag vill jag dela med mig av vad jag lärde mig om att separera apparkitektur i objekt, börja med en snabb introduktion till objektorienterad programmering (OOP).
Det är ett programmeringsparadigm som strukturerar ett program enligt objekt. Enkelt uttryckt, det skapar objekt som innehåller funktioner och data. Detta paradigm förlitar sig mycket på begreppet klasser och objekt.
Med andra ord, i ett OOP-språk skrivs kod för att definiera klasserna och respektive objekt genom att följa fyra principer: inkapsling, abstraktion, arv och polymorfism.
Sök någon annanstans på webben så hittar du snabbt en lista med principer kopplade till OOP. Dessa är: inkapsling, abstraktion, arv och polymorfism. Låt oss se vad dessa principer faktiskt betyder:
Det är dock inte där jag kommer att fokusera på den här artikeln. Åtminstone inte på den mer vetenskapliga versionen av de objektorienterade programmeringsprinciperna. Här hittar du mer praktisk kunskap om objektorienterad programmering och verkliga insikter om hur du kan förbättra konsten förvandla allt till ett objekt. I slutet av den här artikeln kommer det att vara helt klart varför det är relevant för alla som programmerar där ute.
I min programmeringserfarenhet kommer jag alltid att komma ihåg dagen då jag öppnade ett av de stora projekten och mängden filer i det var helt enkelt överväldigande. Det är då jag tänkte: detta är omöjligt att förstå. Konceptet att förvandla en enkel idé till en stor mängd filer verkar vara överdrivet, men ofta är det inte.
För mig är frågan jag ställer mig mest när jag utformar apparkitektur ”ska jag skapa ett objekt för det?” Och för det mesta är svaret helt enkelt:
Ja, jag borde.
Till slut, det är mycket lättare att läsa 10 filer med olika objekt med namn som representerar deras funktion än en enorm hög kod som gör allt. Det enda problemet här är att organisera den stora mängden filer du skapar i en struktur, som kan vara lätt att förstå och söka igenom alla som kan hämta ditt arbete senare.
Som en iOS-utvecklare, Jag följer vad de flesta iOS-utvecklare använder, vilket är MVC-modell, och jag försöker alltid organisera filer i mappar Istället för att bara släppa dem alla på ett ställe.
Istället för att skapa en klass och ge den en uppsättning egenskaper och enumtyper att konfigurera, tänk om det inte vore bättre att bara separera dem i eleganta underklasser för enklare identifiering av vad de faktiskt gör, lämnar basen en tillräckligt generisk för att fortsätta skala den senare.
En av skönheterna med objektorienterad programmering är att klasserna för objekt som du skapar kan återanvändas i andra projekt, vilket är en enorm tidsbesparare. Tänk på det när du skapar objekt och gör dem generiska. Underklassningsmetoden kan definitivt hjälpa dig att göra det.
Det är bättre att separera klassen för att hantera API-anrop eller i appköp för den generiska som du kan använda i dina projekt och underklass med en specifik som hämtar den data du behöver.
Ibland måste jag skapa en metod som kräver att många egenskaper skickas runt. Jag vill inte be om var och en efter en, så jag bestämde mig för att lägga dem alla i en ordbok eller en matris och skicka den.
Det verkar bekvämt nog, men det är det aldrig.
Jag kommer tillbaka till det en månad senare, eller värre, någon annan försöker använda den och de har riktigt svårt att sätta ihop egenskaperna exakt som jag gjorde, och kanske till och med spendera lite tid på att felsöka varför en av dem uppfattas noll på väg.
Till slut, det är mycket lättare att passera hela objektet som fastigheterna tillhör, även om det har mycket mer än du behöver. Denna lösning också skalas bättre eftersom du aldrig vet när du behöver hela objektets sammanhang, även om du börjar bara med en liten del av det.
Alla programmeringsspråk Jag vet att jag är objektorienterad och ändå fortsätter jag att hitta olika sätt att svara på denna enkla fråga: vilken typ av objekt ska representera detta? Mängden möjligheter kan utgöra en utmaning när det gäller objektorienterad programmering, men alternativet att inte använda är varken genomförbart eller önskvärt.
Det objektorienterade programmeringsparadigmet fokuserar på objekt och hur dessa objekt interagerar. Det kräver att utvecklaren planerar kodningen i förväg, vilket leder till bättre datastruktur och möjliggör återanvändbarhet.
Detta paradigm innebär fyra huvudprinciper (inkapsling, arv, polymorfism och abstraktion) som måste följas när man utvecklar en objektorienterad programvara.
När OOP implementeras, några av bästa rekommendationerna utvecklare kan ansöka är:
1. Skapa så många klasser som behövs;
2. Använd fler underklasser;
3. Gör objekt mer generiska;
4. Riv inte föremål isär.
En senior iOS-utvecklare som ingår i ett smidigt iOS-team och ger individer möjlighet att uppnå sina drömmar och mål.
Marknadsföringspraktikant med särskilt intresse för teknik och forskning. På min fritid spelar jag volleyboll och skämmer bort min hund så mycket som möjligt.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(2).webp)
