Share
I den siste opplæringen har vi gjennomgått vår autoloaderes opprinnelige tilstand og gikk gjennom en prosess med objektorientert analyse og design. Hensikten med å gjøre dette er at vi kan knytte sammen alt vi har dekket i denne serien og introduksjonsserien.
For det andre er formålet med å gjøre dette i sin egen veiledning, så vi kan tilbringe resten av denne gangen gjennom klassen vår, se hvordan hver del passer sammen, implementer den i pluginet, og se hvordan man bruker objektorientert programmering og enkeltansvarsprinsipp kan føre til en mer fokusert, vedlikeholdsbar løsning.
På dette punktet antar jeg at du har fulgt med denne serien. Hvis ikke, vennligst se del ett og del to. Denne forutsetter at du har fulgt sammen så langt.
Hvis du er nybegynner, anbefaler jeg at du leser den første serien i sin helhet også. Når du er fanget opp, bør du være i en god posisjon til å fullføre serien som vi konkluderer med resten av kildekoden som er dekket i denne opplæringen.
For å gi et raskt sammendrag og for å sikre at vi alle er på samme side, har vi dekket følgende emner i denne serien:
På dette tidspunktet er vi klare til å bytte ut vår eksisterende autoloader med den objektorienterte baserte koden. Vær imidlertid oppmerksom på at dette ikke vil være et enkelt spørsmål om å endre filer.
I stedet trenger vi å lage filene, sørg for at de følger WordPress-kodingsstandardene, implementer dem, test implementeringen deres for å sikre at pluginet fortsatt fungerer, og fjern deretter eksisterende autoloader.
Det høres ut som mye arbeid, men hvis vår analyse og design fra den forrige opplæringen ble gjort riktig og viser seg å være nøyaktig, burde vi ha lite problem med å gjøre alt som er oppført ovenfor.
Før vi hopper inn i implementeringen, vil jeg gi en rask oversikt over utviklingsmiljøet du burde ha på systemet ditt. Teknisk sett er dette noe du bør allerede ha som kjører i retninger i tidligere opplæringsprogrammer, men jeg vil være så fullstendig som mulig.
Med det sagt, la oss komme i gang.
I denne delen skal vi gå tilbake til all koden som vi har vurdert i den forrige opplæringen; Vi skal imidlertid se på hver enkelt fil sammen med fullstendig dokumentasjon.
I tillegg skal vi inkludere det i prosjektet vårt slik at vi ved slutten av opplæringen kan bruke denne koden i stedet for den enkle prosessbaserte koden vi brukte tidligere.
Vær oppmerksom på at hver av de følgende filene skal være oppført som oppført og skal inkluderes i inc katalogen. Videre er alt dette tilgjengelig for nedlasting ved hjelp av den blå knappen i sidefeltet i dette innlegget.
namespace_validator = nytt NamespaceValidator (); $ this-> file_registry = ny filregistrering (); / ** * Forsøk på å laste det angitte filnavnet. * * @param string $ filnavn Banen til filen vi prøver å laste inn. * / offentlig funksjonsbelastning ($ filnavn) if ($ this-> namespace_validator-> er_valid ($ filnavn)) $ this-> file_registry-> last ($ filnavn);
class-fil-investigator.php
get_file_name ($ file_parts, $ current, $ i); hvis (telle ($ file_parts) - 1! == $ i) $ filepath = trailingslashit ($ filepath); returnere $ filepath; / ** * Henter plasseringen av en del av filnavnet på disken basert på den nåværende indeksen for * -serien som undersøkes. * * @access private * @param array $ file_parts Arrayen av alle deler av filnavnet. * @param string $ current Den nåværende delen av filen for å undersøke. * @param int $ i Den nåværende indeksen for arrayet av $ file_parts å undersøke. * @return string Navnet på filen på disken. * / privat funksjon get_file_name ($ file_parts, $ current, $ i) $ filnavn = "; hvis (count ($ file_parts) - 1 === $ i) if ($ this-> is_interface ($ file_parts)) $ filename = $ this-> get_interface_name ($ file_parts); annet $ filnavn = $ dette-> get_class_name ($ current); annet $ filnavn = $ dette-> get_namespace_name ($ current); returner $ filnavn ; / ** * Bestemmer om den angitte filen som undersøkes er et grensesnitt. * * @Access private * @param array $ file_parts Delene av filepathen for å undersøke. * @Return bool True hvis grensesnitt er inneholdt i filnavnet, ellers , false. * / privat funksjon is_interface ($ file_parts) return strpos (strtolower ($ file_parts [count ($ file_parts) - 1]), 'grensesnitt'); / ** * Henter filnavnet til grensesnittet basert på Spesifiserte deler av filen passerte * i autoloader. * * @access private * @param array $ file_parts Arrayen av deler av filen som skal undersøkes. * @return string Filnavnet til grensesnittet. * / private fu nction get_interface_name ($ file_parts) $ interface_name = eksplodere ('_', $ file_parts [count ($ file_parts) - 1]); $ interface_name = $ interface_name [0]; returnere "grensesnitt- $ interface_name.php"; / ** * Genererer navnet på klassenavnet på disken. * * @access private * @param string $ current Den nåværende delen av filnavnet for å undersøke. * @return string Klassen filnavn på disk. * / privat funksjon get_class_name ($ current) return "class- $ current.php"; / ** * Oppretter en kartlegging av navneområdet til katalogstrukturen. * * @access private * @param string $ current Den nåværende delen av filen for å undersøke. * @return string Stien til navneområdet kartlegger til katalogstrukturen. * / privat funksjon get_namespace_name ($ current) return '/'. $ Strøm;class-fil-registry.php
investigator = ny FileInvestigator (); / ** * Bruker filen etterforsker for å hente plasseringen av filen på disken. Hvis funnet, så * vil det inkludere det i prosjektet; Ellers vil det kaste en WordPress feilmelding. * * @param string $ filepath Banen til filen på disken for å inkludere i plugin. * / offentlige funksjonsbelastning ($ filepath) $ filepath = $ this-> investigator-> get_filetype ($ filepath); $ filepath = rtrim (plugin_dir_path (dirname (__FILE__)), '/'). $ Filepath; hvis (file_exists ($ filepath)) include_once ($ filepath); ellers wp_die (esc_html ('Den angitte filen eksisterer ikke.'));Inkludert filene, starter autoloader
Nå som vi har opprettet våre filer, må vi lage to små endringer:
- Vi må inkludere alle klassene i inc kataloget.
- Vi trenger å kvitte seg med den gamle autoloaderkoden.
- Og vi må bruke vår nye autoloader med
spl_autoload_registerfunksjon.Til slutt bør den endelige versjonen av autoload.php se slik ut:
Og det vil utføre nøyaktig hva vi har skissert over.
Men vent, jeg får en feil!
På dette punktet har du gjort mye arbeid. Du har refactored hele autoloaderen til å bruke objektorientert programmering. Du har dokumentert dine klasser og funksjoner. Du har opprettet nye filer, fjernet kode fra gamle filer, og du er klar til å kontrollere at alt fungerer som forventet.
Så, som noen utvikler ville gjøre, starter du nettleservinduet for å oppdatere siden, bare for å bli vist en feilmelding:
Heldigvis er dette en enkel løsning. Problemet er at vi forsøker å legge til meta-boksen for tidlig. For å fikse dette, oppdaterer vi
i detmetode i vårMeta_Boxklasse for å inkludere dette:Og så vil vi introdusere en funksjon som vil bli hekta på det arbeidet vi nettopp gjorde:
vise, gjengi), 'innlegg', 'side', 'høy');På dette tidspunktet bør du kunne utføre den nye koden uten problemer, ingen advarsler, ingen merknader og ingen feil.
Konklusjon
Å jobbe gjennom alt dette kan ha virket som mye - og det var! Men det fine er at det dekket mye bakken i tre opplæringsprogrammer, og Det ble bygget på arbeidet i en tidligere serie. I den forbindelse ble mange nye emner dekket og nye teknikker ble lært.
Merk at jeg skriver regelmessig for Envato Tuts +, og du kan finne alle mine tidligere opplæringsprogrammer på min profilside. I tillegg diskuterer jeg ofte programvareutvikling i sammenheng med WordPress på bloggen min og på Twitter, så følg meg fri til å følge meg på begge steder.
Med det sagt, studer koden vi har dekket gjennom hele denne serien (og kanskje den som er før den), og se om du ikke kan bruke noen av disse teknikkene i ditt eksisterende eller fremtidige arbeid.
ressurser
Accentsconagua
