Snabb prototyping med WordPress: konceptanalys
I förra inlägget började jag gå igenom processen att ta idén till ett plugin som snabbt prototypar det till något som fungerar inom WordPress. Och även om det fungerar, följer det inte nödvändigtvis några objektorienterade principer, och det är inte heller på ett ställe där vi enkelt kan fortsätta att lägga till funktioner.
Nej, detta är inte ett argument för varför objektorientering är bättre. Det råkar vara mitt föredragna sätt att skriva kod så jag närmar mig det så här.
Jag vet att exempelkoden jag ger är enkel och jag vet att man kan göra ett fall att något sådant här kan lämnas som det är. Men poängen med detta är att visa hur man tar ett koncept, prototypar det och sedan flyttar det till något som följer objektorienterade principer.
Och enligt min erfarenhet är det mycket svårare att göra det med ett komplext exempel från början. om du tappar läsare från början, vilket hopp finns det då för att de ska förstå vad som kommer?
Så med det sagt, vi ska ta en titt på koden från föregående inlägg och göra lite av en konceptanalys på den för att se vad som kan fungera bra inom en klass och hur vi kan börja organisera den med hjälp av klasser, namnutrymmen och så vidare.
Konceptanalys
Närhelst det kommer till programmering är det så lätt att vilja hoppa in i att omedelbart skriva kod och sedan tjafsa om den till inlämning tills den gör något som vi vill.
Och när det väl fungerar känns det som att vi är klara och vi kan gå vidare till nästa uppgift. Men för större projekt är det inte alltid så. Faktum är att det ofta är bättre att göra lite konceptanalys av objektorienterad analys på din design innan du går vidare.
Att bara hoppa in i kodning är inte alltid det bästa sättet.
Ett fall för analys
Exempel: När detta skrivs diskuterar jag och en av mina lagkamrater om vi ska utöka en klass eller skriva en ny klass för att hantera geolokaliseringsinformation för data hämtade från Google Maps API.
Kan jag ving den och skriva något som fungerar? Säker. Men kommer det att integreras bra med applikationen? Inte utan konceptanalys, planering och samordning med resten av systemet.
Och det är vad syftet med analysen handlar om.
Analysera vårt arbete
Så vad betyder detta för pluginet vi tittade på igår? Just nu har vi följande:
- en funktion som ansvarar för att skapa en metabox och visa innehållet i den,
- en funktion för att söka i databasen och hämta de senaste inläggen,
- en funktion för att visa resultaten i metarutan
- en funktion för att visa ett meddelande när det inte finns några resultat i metarutan
Vidare är ett antal av dessa funktioner relaterade till krokar som är en del av WordPress API. Funktionen för att skapa metaboxen är nämligen kopplad till WordPress och dess följefunktion för att rendera displayen är alla en del av samma komponent.
Sedan har vi funktionalitet för att söka i databasen och vi har funktioner direkt relaterade till vyer.
Så hur skulle det här kunna se ut om vi skulle rita upp det här i olika klasser och filer som skulle hjälpa till att skapa detta på ett mer objektorienterat sätt?
Ingen enskild lösning
Det finns ingen enskild lösning och vissa lösningar är mycket mer avancerade än andra. Men eftersom jag försöker hitta en balans här, kommer jag att närma mig det här på ett enklare sätt än att arbeta för mycket med abstraktion, arv, gränssnitt och allt det där.
Fokusera på det vi har
Låt oss nu fokusera på enskilda klasser och det ansvar de kan ha. Till exempel:
- Jag tror att vi kommer att behöva en klass som representerar metaboxen. Detta bör vara ansvarigt för att skapa metaboxen.
- Vi behöver också en klass som ansvarar för att visa innehållet i metaboxen. Du kanske tycker att det fungerar bra att inkludera en funktion i klassen för metaboxen. Det gör det; men om du vill tänka på att varje klass har ett enda ansvar, kan vi skapa en klass specifikt för displayen och specifikt för metaboxen, och sedan injicera displayen i metaboxen under instansieringen. Vi kommer att prata mer om detta senare.
Vid det här laget kan vårt diagram se ut ungefär så här:
Att bryta ner metaboxen.
Därefter måste vi överväga den andra funktionaliteten. Nämligen funktionaliteten för att visa resultaten i metarutan och funktionaliteten för att visa resultaten när det inte finns några.
För att kunna visa något i metarutan måste vi ha ett sätt att fråga databasen för att hämta resultaten. Därifrån måste vi sedan kunna ha ett sätt att avgöra om det finns resultat, om det inte finns det och sedan injicera dessa resultat i vyn.
Med tanke på denna information låter det som att vi behöver en klass för att söka i databasen och sedan behöver vi en klass för att bredda ett meddelande till displayen i metarutan.
Ett sätt att organisera klasserna skulle kanske se ut så här:
Fråga i databasen och förbereda meddelanden.
Den slutliga versionen av diagrammet kan vara lite trångt men vi tittar i slutändan på något så här:
Den slutliga organisationen för våra klasser.
För förklaringsändamål:
- Posthämtaren frågar databasen efter de tre senaste inläggen.
- Postbudbäraren avgör vilket meddelande som ska injiceras på displayen.
- Displayen visar meddelandet som har ställts in.
- Metarutan återger sin visning till webbläsaren.
Så vi har i princip tagit några funktioner som kopplats till WordPress och delat upp dem i komponenter som kan kommunicera med varandra, som var och en är relativt lätt att arbeta med och inte gör mer än ett enda jobb.
Konvertera den till kod
Nu när vi har en idé om hur vi kan konvertera det tidigare konceptet till kod, ska vi titta på hur man gör det i de kommande artiklarna.
Observera att hur du väljer att implementera din kod eller designa dina klasser kan vara lite annorlunda än vad jag har ovan och du kan ha förslag på hur du bättre kan organisera det som står ovan. Om så är fallet, lämna en kommentar.
I nästa inlägg kommer vi att titta på att konvertera detta till funktionell kod och efter det kommer vi att titta på att organisera detta i rätt namnutrymmen och korrekt filorganisation.
Serie inlägg
- Snabb prototyping med WordPress: från koncept till plugin
- Snabb prototyping med WordPress: konceptanalys
- Rapid Prototyping: Prototype To Code, del 1
- Rapid Prototyping: Prototype To Code, del 2
- Rapid Prototyping: Introduktion av Autoloading