Share
Denne delen to av en serie ser på to forskjellige programmeringsstiler (noen ganger kalt programmeringsparadigmer) som du kan bruke når du skriver WordPress-plugin-moduler. I del en Tom McFarlin dekket objektorientert programmering. I denne delen ser vi på funksjonell programmering.
Fordi erfaringsnivået til leserne varierer, skal vi snakke om programmering på høyt nivå, så hvis du er nybegynner, bør du ikke ha noe problem å følge med. Hvis du imidlertid er en mer erfaren utvikler, kan du finne mer nyttig informasjon senere i artikkelen.
Funksjonell programmering er sannsynligvis den stilen du er mest kjent med - og nesten universelt - er den stilen som brukes i de ulike WordPress-kodesider som flyter rundt på internett. Av denne grunn kan det noen ganger ses som "inngangsnivå" programmering: stilen ansatt av nybegynnere til de har lært å mestre objektorientert programmering. Dette er utrolig misvisende, fordi mens funksjonell programmering er mye enklere, er det ikke i seg selv dårligere.
Funksjonell programmering legger vekt på evaluering av funksjoner og unngår begrepet stater eller objekter i motsetning til objektorientert programmering som oppfordrer til å tenke på kode som å fungere på objekt (er), ved hjelp av metoder for å endre disse objektene, eller samhandle med dem. La oss se på et veldig enkelt eksempel som sammenligner de to stilene:
// Funksjonell metodefunksjon add_two ($ n) return $ n +2; $ a = 2; $ b = add_two ($ a); // $ b = 4; // Objektorientert metodeklasse Nummer var $ verdi = 0; funksjon __construct ($ a) $ this-> value = $ a; funksjon add_two () $ this-> value = $ this-> value +2; $ a = nytt nummer (2); ekko $ a-> verdi; // Skriver 2 $ a-> add_two (); ekko $ a-> verdi; // Skriver 4
Dette veldig enkle eksemplet illustrerer den grunnleggende forskjellen i stilen til de to paradigmene: funksjonell programmering fokuserer på å overføre argumenter til og motta verdier fra funksjoner. Det er ingen "objekter" som blir handlet på, bare parametere og returverdier. Omvendt tilordner objektobjektiv tilnærming et objekt forskjellige egenskaper (i vårt tilfelle en 'verdi') og metoder virker på disse egenskapene.
Definere funksjoner er veldig enkelt:
funksjon add ($ number, $ number2 = 1) // Utfør kode som virker på bestått variabler $ sum = $ nummer + $ number2; // Valgfritt, hvis nødvendig kan du returnere en verdiavkastning $ sum;
Når funksjonen er erklært, kan den brukes hvor som helst i plugin-modulen, med andre ord har den et globalt omfang.
$ a = 4; $ b = 7; ekko add ($ a, $ b); // Utskrifter 11Funksjoner må ha unike navn. Redeclaring en funksjon vil kaste en feil. Siden koden din kjører sammen med andre plugin-moduler, temaer og WordPress selv, bør du aldri bruke generiske navn. I stedet bør du prefiks funksjonsnavnene dine med noe unikt (som navnet på plugin-modulen din).
Du har kanskje lagt merke til det i definisjonen av Legg til, Det andre argumentet er satt lik 1. Dette angir en standardverdi for $ tall2 (i dette tilfellet 1), og dermed gjør argumentet valgfritt. Hvis argumentet ikke leveres, er verdien tatt som standardverdien:
ekko add (4); // Skriver 5 ekko add (4, 1); // Skriver 5
På den annen side er ingen standardverdi gitt for den første verdien, så utelatelse av argumentet vil kaste en feil
ekko add (); // Kaster en feil da $ nummer ikke er definert
Du kan også ha et variabelt antall argumenter. Inne i funksjonen vi kan bruke func_num_args () for å få antall argumenter mottatt, mens func_get_arg () gir deg tilgang til en bestemt bestått variabel, indeksert fra 0.
funksjon sum () // Få antall argumenter gitt til summen () $ number_args = func_num_args (); $ sum = 0; hvis (! $ number_args) returnerer $ sum; for ($ i = 0; $ i < $number_args; $i++ ) $sum += func_get_arg( $i ); return $sum; echo sum( 1, 2, 3, 4 ); //Prints 10 echo sum( 1, 2 ); //Prints 3 echo sum(); //Prints 0
Ovennevnte kan også brukes i objektmetoder. Til slutt, ved å erklære en variabel som "global", kan du få tilgang til variabelen fra innsiden av en funksjon.
$ a = 'Hei'; $ b = 'Verden'; funksjon hello_world () // Dette er nødvendig for å få tilgang til $ a og $ b // deklarert utenfor funksjonens omfang. global $ a, $ b; $ b = $ a. ". $ b; hello_world (); echo $ b; // Utskrifter 'Hello World'Bruke globals er generelt motløs. Spesielt siden to plugin-moduler som bruker samme navn for en global variabel, kan føre til at en eller begge plugin-modulene bryter. Hvis du må bruke en global variabel, må du på nytt sørge for at den er unik ved å prefikse med navnet på plugin-modulen.
Bestemme hvilken programmeringsstil som skal brukes, kommer ned til dommen - og ja - personlig preferanse. Det er ikke mer riktig eller galt å bruke funksjonell over objektorientert programmering, men oftere enn ikke er det en stil som passer bedre til det du prøver å oppnå.
Noen ganger er objektorientert programmering ikke nødvendig, og bare over kompliserer saker, eller introduserer overflødig kode. Et eksempel kan være de forskjellige "verktøyfunksjonene" som WordPress tilbyr. Dette er generiske funksjoner som tjener til å utføre en bestemt hensikt. For eksempel wp_trim_words ($ tekst, $ num_words) enkelt trimmer den oppgitte strengen til en viss størrelse (i ord). Det vil ikke legge til noe som skal defineres wp_trim_words () i stedet som en metode som tilhører noe objekt, og vil resultere i ugligere kode. Med funksjonell programmering tar det en linje.
En fordel med funksjonell programmering, spesielt for nybegynnere, er dens enkelhet. Du trenger ikke å bekymre deg for statiske, private eller beskyttede funksjoner - de er alle globale. Begrepet statiske variabler eksisterer heller ikke. På det grunnleggende nivået returnerer funksjonen en utgang avledet av hva du har gitt den. For eksempel, get_the_title (7) vil returnere tittelen for innlegget med ID 7.
En annen fordel med funksjonell programmering er at funksjonene er tilgjengelige globalt. Med objektorienterte programmer må du passere rundt objektet for å kunne fungere på en bestemt gjenstand. Dette kan noen ganger være vanskelig. For å illustrere dette, la oss ta et eksempel fra første del:
Accentsconagua
klassen DemoPlugin offentlig funksjon __construct () add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); offentlig funksjon register_plugin_scripts () // Registrer plugin scripts $ demo_plugin = ny DemoPlugin (); Når WordPress lagrer register_plugin_scripts () metode slik at det kan kalles når wp_enqueue_scripts handling utløses gjør det ved å referere ikke bare til metoden, men også objektet $ demo_plugin. Dette skyldes at samme metode for ulike forekomster av et objekt vurderes forskjellig metoder - det vil si, $ Demo_plugin-> register_plugin_scripts () og $ Copy_of_demo_plugin-> register_plugin_scripts () er ikke det samme. Dette kan virke rart - men metoder kan oppføre seg annerledes for forskjellige forekomster av samme klasse, så vi må referere til både metode og eksempel.
Men hvorfor betyr dette? Det gjør det svært vanskelig for en tredjepart-plugin eller et tema for å avhende den metoden, siden de måtte ringe:
remove_action ('wp_enqueue_scripts', array ($ demo_plugin, 'register_plugin_scripts')); Men generelt vil de ikke ha tilgang til $ demo_plugin variabel. (Merk: Hvis metoden er deklarert statisk, kan du komme rundt dette).
Selvfølgelig har objektorientert programmering sine fordeler, som diskutert i del ett. Som Tom også nevnte, er det uunngåelig når du bruker WordPress 'widget-API. Et annet vanlig eksempel er WP_Query (). Her er en objektorientert tilnærming klart det beste: du har et objekt (i dette tilfellet et spørsmål), som har forskjellige egenskaper (dvs. søkekriterier, paginasjonsinformasjon, matchende resultater) og du vil opptre på den forespørselen (analyser den, generer og desinfiser den tilsvarende SQL, og returner resultatene).
WP_Query () demonstrerer hvor kraftig objektorientert programmering kan være når den brukes riktig. Etter at du har startet spørringen:
$ the_query = ny WP_Query (array (...));
Ikke bare kan du få tilgang til resultatene, men også andre opplysninger, for eksempel paginasjonsverdier: hvor mange sider med resultater er det, hvilken side som blir vist, totalt antall resultater og typen av spørring, f.eks.. $ The_query-> is_search (), $ The_query-> is_single () etc. Det er også hele "loop" -infrastrukturen;
hvis ($ the_query-> have_posts ()) echo '
Som skjuler alle interne jonglering av resultater og globals bak en menneskelig vennlig API.
Så hva med get_posts ()? Dette tjener bare som en wrapper for WP_Query (), og returnerer ganske enkelt en rekke innlegg som samsvarer med spørringen. Som sådan får du ikke "klokkene og fløyter" av WP_Query (), men det er litt mer effektivt. Så om du skal bruke get_posts () eller WP_Query () Avhenger av brukssaken din (for eksempel om du trenger paginering eller ikke), men det er også ned til personlig preferanse.
$ results = get_posts (array (...)); hvis ($ resultater) echo '
Forhåpentligvis har disse to artiklene bidratt til å markere fordelene og ulempene ved disse programmeringsstilene. Ta bort punktet er at det ikke er noe riktig og galt her, og hver programmerer vil ha sin egen personlige preferanse. Men enkelte sammenhenger gir seg mer lett til en bestemt programmeringsstil - og som sådan bør du forvente at plugin-modulen din inneholder en blanding av begge.
