Rapid Prototyping: Prototype To Code, del 2

Senaste uppdateringen nov 9, 2022

Innehåll

Nu är vi organiserade (med ett undantag)

Det tidigare inlägget visar mycket arbete med att ta något som en gång var en snabb prototyp och ta den prototypen till kod. Om du inte har följt med har vi gjort följande:

pratade om och byggde en prototyp för ett plugin,
i diagrammet kan ett objektorienterat tillvägagångssätt fungera,
och refaktorerade vår prototyp till faktisk kod.

Vid det här laget finns det några fler saker vi kan göra för att förbättra vår kod. Vi kan nämligen introducera begreppet namnrymder. Detta tar organisationen ett steg längre och kan ge utdelning för större projekt.

Så här är en titt på hur detta ser ut i vårt nuvarande projekt.

Prototyp att koda: Namnutrymmen

Jag har täckt namnutrymmen på djupet i tidigare inlägg. Om du inte har läst den rekommenderar jag den. Kom sedan tillbaka och kolla in resten av inlägget.

Om du väljer att hoppa över artikeln, här är en kort definition av ett namnområde :

Namnområden är designade för att lösa två problem som författare till bibliotek och applikationer stöter på när de skapar återanvändbara kodelement som klasser eller funktioner…

Och den allmänna tanken är att vi organiserar våra klasser utifrån en logisk relation de har med varandra.

Dessutom organiserar vi även filerna i kataloger som matchar namnområdet. Detta är inget som måste göras, men jag tycker att det hjälper att ha klasserna logiskt organiserade på disken på det sätt som de är virtuellt organiserade i namnutrymmet.

Med det sagt, låt oss organisera filerna.

Organisera filerna

Istället för att börja med huvudpluginfilen, låt oss börja med att organisera våra filer först.

Filerna Meta Box och Meta Box Display kommer att finnas i en katalog som heter Display. Detta är helt godtyckligt, men eftersom det är vad dessa filer gör, verkar det vara logiskt att det är där de skulle ligga.
Vi kan också placera filerna message-description.php och no-post-list.php i den katalogen, men låt oss placera dem i en underkatalog som heter Views. Du kanske vill kalla detta för mallar eller partier eller något liknande.
Därefter har vi klasserna som ansvarar för att fråga databasen och klassen som ansvarar för att koordinera meddelanden. Låt oss placera var och en av dessa i Utility. Det finns andra ställen de kan gå till, men kom ihåg att syftet är att visa hur man använder namnutrymmen. Så om du känner dig så sugen, justera gärna dina filer så att de passar dig.

Om du har följt det vi har ovan bör du ha en katalogstruktur som ser ut ungefär så här:

Ett sätt att organisera dina filer.

Nu är det dags att definiera namnutrymmen för var och en av klasserna. Eftersom vi har organiserat dem alla i deras kataloger blir det lätt att ange ett namnområde; Det är dock viktigt att inse att vi måste använda nyckelordet use när vi använder klasser som finns i andra namnutrymmen.

Låt oss gå igenom alla våra filer och börja med filerna i Utility. Först börjar vi med Post Messenger :

Du kommer att märka att namnutrymmet för filen visas i rubriken tillsammans med en deklaration om att använda klassen Post Query som vi skapade. Jag har lagt till namnet på klassen i slutet av namnutrymmet, så jag behöver inte använda det i hela kodbasen.

Lägg märke till att konstruktören nu ser ut så här :

Jag har lagt till ett $plugin_dir- argument eftersom vi måste använda detta för att visa resultaten av frågan korrekt. Och eftersom de nu finns i ett annat område av applikationen ser funktionerna ut så här :

Låt oss sedan titta på klassen Post Query. Ingenting mycket har förändrats i den här klassen förutom att vi har gett den ett namnutrymme, och vi har också uppdaterat frågan för att bara dra tillbaka tre inlägg (enligt den här kommentaren ).

Lägg märke till i koden, jag har också förfixat WP_Query med ett snedstreck eftersom det är en del av det globala namnområdet.

Låt oss gå in i Display – katalogen och ta en titt på Meta Box-klassen. Detta har också fått ett namnutrymme och använder också det fullt kvalificerade namnet på Meta Box Display -klassen som vi kommer att titta på ett ögonblick.

Lägg märke till att den här konstruktören också accepterar plugin-katalogen som ett argument och skickar den till Meta Box Display -klassen också. Detta är för att de funktioner som ansvarar för att visa meddelanden kan hittas på rätt plats i katalogen Views .

Låt oss slutligen se över Meta Box Display -klassen. Det här är en enkel klass som inkluderar namnutrymmet och refererar till Post Messenger som vi har granskat ovan.

Vid det här laget har vi kommit en runda genom plugin-programmet. Med ett undantag: Bootstrap-filen. Vi har lagt till ett namnområde till det och måste uppdatera sättet som det instansierades på :

Vi har nämligen:

definierade namnutrymmet,
referera till platsen för Meta Box -klassen,
uppdaterade sökvägarna för att inkludera var man kan hitta filerna (vilket i slutändan kan göras med en autoloader),
och uppdaterade add_action -anropet.

Det här är grejen med add action-anropet: Eftersom WordPress behöver hitta den här funktionen och funktionen finns i ett namnområde, måste det fullständiga namnet på funktionen identifieras så att WordPress kan anropa den. Därav behovet av NAMESPACE i funktionens namn.

Nu är vi organiserade (med ett undantag)

Som du märker lägger namnutrymmen och kataloger som matchar dem mycket organisation till ett projekt. Det är lättare att följa, lättare att förstå var saker och ting tar vägen (för både befintliga och nya filer). Och det ger mindre känsla att bara samla många filer på en enda plats.

Även om en klass är lite av en monolit, kan den fortfarande organiseras på ett sådant sätt som gör underhållet enkelt.

Med det sagt finns det fortfarande något jag skulle ändra på det här pluginet: Att gå runt i katalogen för plugin-programmet så här är inte något som hjälper till med låg sammanhållning och det kopplar ihop klasserna tätare eftersom bootstrap-filen måste skicka ett värde till en klass som skickar den till en annan klass som använder den för att ladda filer och så vidare.

Så finns det sätt att fixa detta? Absolut. Och det kanske vi tar en titt på i det sista inlägget.

Tills dess, kom ihåg att den senaste versionen av insticksprogrammet är tillgängligt på huvudgrenen, taggad som 0.3.0, på GitHub.

Serie inlägg

Inspelningskälla: tommcfarlin.com