Objektorienterad programmering i WordPress: Analys, del 2
I det första inlägget i den här serien pratade jag allt om hur jag ville ta mig an en introduktion till objektorienterad programmering inom WordPress-sammanhang.
Det finns några bra resurser för objektorienterad programmering men de kan använda konstruerade exempel, eller så kan de gå för snabbt för dem som bara vill komma igång.
I ett försök att förhindra att detta händer, tror jag att det att prata om OOP i WordPress förankrar oss på en stark grund och att använda praktiska exempel kommer alltid att vara bättre än att använda generiska exempel som är svåra att översätta till den domän där vi arbetar.
För de som ännu inte har gått med eller som inte har kommit ikapp ännu, det första inlägget träffar följande ämnen:
- Objektorienterad analys,
- Bestämma måste-has kontra Nice-to-haves,
- Och varför är det svårt?
Och det är där detta inlägg kommer att plocka upp.
Objektorienterad programmering: mer analys
Jag vet: När det kommer till att skriva kod är det första vi vill göra att sätta oss ner och börja skriva kod. Vad är bättre än att få något att hända på skärmen?
Och när du gör det här för dig själv är det inte så stor sak, men när du skriver kod kommer det att vara:
- underhålls av ett team av människor,
- till salu,
- eller för alla ovanstående
Det gör skillnad. För bra analys kan leda till bra organisation som kan leda till god underhållsbarhet.
Annars klappar du ihop något för att skicka, och det kommer inte att skala bra med framtida versioner. Och det här är något vi kommer att prata om på djupet genom hela serien.
Men vad är ett bra sätt att sammanfatta att göra bra analys i tre enkla steg? Det här är inte nödvändigtvis ett skottsäkert svar, men det är vad vi försöker göra när vi arbetar med projekt:
- Se till att koden gör vad kunden vill ha,
- Tillämpa goda objektorienterade metoder,
- Sträva efter en underhållbar design.
Allt detta låter bra i teorin, men utan att ta en djupare dykning i varje, hur vet vi om vi gör det här rätt? Med andra ord, det är här vi ofta hittar böcker, resurser och andra verktyg som gör det svårt att bli en bättre objektorienterad programmerare.
Det är precis det jag vill undvika, så jag ska gräva lite djupare i varje punkt.
1 Vad kunden vill ha
Detta kan vara en av de mest utmanande aspekterna av hela projektet ofta eftersom vi som utvecklare talar ett annat språk kunden.
Inte nog med att de ofta använder terminologi som vi inte skulle använda, de tror ofta att det de vill ha på skärmen är det bästa sättet att gå tillväga. Detta gör att det låter riktigt nedlåtande och fel att försöka rätta till dem, eller hur?
Jag menar, tänk dig att försöka berätta för någon att du vet vad du vill, och de rättar dig. Att hantera detta med omsorg är något som kan få stor relationell rättvisa men det tar en viss tid att "gräva ut" vad det är de verkligen vill ha kontra vad de säger att de vill ha.
Och vi kommer att dyka ner i detta mer i ett framtida inlägg.
2 Objektorienterade metoder
Uppenbarligen kommer detta från att veta vad de goda objektorienterade metoderna är och det är något som jag planerar att täcka.
Många människor kommer att säga saker med saker som:
- SOLID principerna,
- arv,
- DRY kod,
- beroendeinjektion,
- och så vidare
Alla är viktiga för att följa goda objektorienterade metoder.
Och det kanske inte är en populär sak att säga, men jag är av inställningen att det inte alltid är en bra idé att försöka använda alla saker hela tiden. Dvs du vill definitivt inte ha kod upprepad genom hela din kodbas, men måste du ha arv i din kodbas?
Nej.
Det finns tillfällen då principer bör tillämpas och när de kan ignoreras. Men att känna till dem, när de används bäst och när de ska användas är nyckeln för att använda dessa metoder på rätt sätt.
3 Underhållbar design
Enkelt uttryckt, att tillämpa mönster och principer på din programvara när du skriver den är det som kommer att göra det mycket lättare att använda och underhålla i framtiden.
Men återigen, detta är beroende av:
- full förståelse för vad kunden vill ha,
- att veta vilka metoder som finns, när de ska tillämpas och när de ska undvikas.
Och för att göra allt ovanstående måste vi titta på varje punkt inom sitt sammanhang innan vi tar ett steg tillbaka för att titta på den större bilden.
Vad vill kunden ha?
Uppenbarligen finns det mycket mark att täcka när det kommer till ovanstående tre punkter. Men om du vill skriva bra, underhållbar programvara inom WordPress-ekonomin är det viktigt att förstå hur allt detta hänger ihop.
Så i stället för att gå vidare med att skriva kod eller att börja arbeta med ett projekt, är nästa sak vi ska undersöka hur vi ska ta vad kunden vill ha och sedan dechiffrera det till en uppsättning krav som gör att vi kan skapa en arbetsförklaring.
På så sätt kommer vi i slutändan att ha ett arbetsdokument över vad kunden vill ha och vad vi ska bygga, och vi kommer alla att vara på samma sida.