Objektorienterad programmering i WordPress: Analys, del 1
När jag först ville erbjuda medlemskap på den här webbplatsen visste jag att det första jag ville ta itu med var en introduktion till objektorienterad programmering.
Det är något som verkar vara intressant för de flesta som arbetar i WordPress, men det finns ett problem som antingen avvisar många människor eller genererar dåliga resultat:
Objektorienterad programmering kan bli komplicerad snabbt. Och det här blir demotiverande.
Så här menar jag: Säg att du är en WordPress-utvecklare som börjar forska i objektorienterad programmering. Det börjar prata om klasser och konstruktörer och funktioner, och allt verkar bra.
Men sedan kommer det snabbt in:
- privata och skyddade metoder,
- arv,
- polymorfism,
- Design mönster,
- beroendeinjektion,
- förråd,
- och så vidare.
Det snöar, eller hur? Och det är inte alls så det måste vara, men det är svårt att hitta en ordentlig introduktion förutom några resurser som finns där ute.
Med allt detta sagt (och som en bakgrund för vart jag är på väg), ville jag sätta mig in i att skapa en serie innehåll för dem som:
- är genuint intresserad av objektorienterad programmering,
- vet inte var jag ska börja,
- vill utveckla sina kunskaper,
- vill börja från noll utan att eskalera till mer komplicerat material för snabbt.
Och det är vad jag börjar idag och i den första stora seriösa planerade för medlemmarna. Med allt detta sagt, låt oss börja.
Specifikt, låt oss börja prata om objektorienterad programmering, analys, design och varför hon borde börja där.
Objektorienterad programmering: Analys
När det gäller att skriva kod finns det för närvarande tre populära sätt att göra det:
Närhelst vi arbetar med och läser WordPress-kod kommer du att läsa en kombination av procedurkod och objektorienterad kod.
Det finns några anledningar till att detta är fallet, men det ligger utanför ramen för vår diskussion.
Detta beror på att WordPress är byggt med både och för att vissa aspekter av WordPress-utveckling kan skrivas med procedurkod, som plugins och teman, och andra kräver objektorienterad utveckling som widgets.
Analys och design
Så ofta är det första vi vill göra, som utvecklare (blivande eller inte), att genast börja skriva kod. Jag får också. Det är kul. Vi har en idé, vi vill förverkliga den, vi vill börja använda den och vi vill visa den för andra människor.
Men här är problemet med att göra det: Vi hoppar ofta direkt till att skriva kod för att försöka få projektet att göra vad vi vill att det ska göra.
Om det här är ett enkelt (och jag menar verkligen enkelt) projekt, så är det inte så stor sak. Ärligt talat, jag har gjort det (och GitHub är ett bevis på det). Men när det kommer till arbetet vi gör på Pressware ; det är en annan historia.
När det kommer till sådana projekt vill vi göra lite Analys och Design innan vi skriver kod.
Vilket väcker frågan, vad är objektorienterad analys och design?
Analys
Kort sagt, tänk på det så här:
Analysen är processen att ta idén som kunden eller som du har och gräva fram vad som verkligen behöver byggas.
Detta kan hjälpa dig att avgöra vad som är fördelen med applikationen och vad som inte är nödvändigt för den första versionen av applikationen. Jag gillar att märka dessa så långt som "måsten" och vad som är "trevliga att ha".
En bra tumregel är denna:
- måste-has är de saker som är kärnan i applikationen och måste gå in i den första iterationen av projektet,
- trevliga att ha är de saker som vi så småningom kan bygga in i den
I slutändan hjälper detta oss att arbeta mot en stark första version för kunden. Ett exempel är kanske för WordPress:
- Behövde den första versionen av WordPress ha ett plugin-API eller behövde den bara ha möjlighet för människor att skriva inlägg och publicera dem på webben?
Om du bygger en plattform för att blogga, måste den kunna utökas från den första versionen? Detta är inget annat än ett exempel, men du förstår tanken.
Vad gör analys så svår?
Jag tror att det ofta har med personas att göra.
Till exempel tycker vi som programmerare att ett projekt alltid ska göra som kunden vill. Sanningen är att det inte alltid är fallet.
Jag menar, så småningom kan det bli det, men den första versionen av projektet behöver inte nödvändigtvis vara så.
Dessutom är en av de objektorienterade programmeringsprinciperna att vi inte skriver en massa duplicerad kod. Men det kan vara mycket svårt att göra om korrekt analys inte har gjorts.
Slutligen kommer de som är mer erfarna att säga att bra programvara kommer att använda beprövade och sanna principer – vare sig det är designmönster eller inte – men att den lätt kan ändras över tid. Som på sätt och vis växer organiskt.
Så vad ska vi göra?
I nästa artikel kommer jag att prata om tre saker vi kan göra som utvecklare för att se till att mjukvaran vi bygger åt oss själva eller andra tar oss i rätt riktning.
Jag kommer inte säga att det är en silverkula eftersom jag inte tror att det finns, men jag kommer att säga att det är ett ganska starkt tillvägagångssätt som jag har hittat andra att använda och bra som mig själv och att det leder till en ganska bra riktning när det gäller objektorienterad analys.
Detta kommer så småningom att ta oss till design. Men vi är inte där än.