Share
Dit deel twee van een serie kijkt naar twee verschillende programmeerstijlen (ook wel programmeerparadigma's genoemd) die je kunt gebruiken bij het schrijven van WordPress plug-ins. In het eerste deel behandelde Tom McFarlin objectgeoriënteerd programmeren. In dit deel zullen we kijken naar functioneel programmeren.
Omdat het ervaringsniveau van lezers varieert, gaan we het hebben over programmeren op een hoog niveau, dus als je een beginner bent, zou je geen probleem moeten hebben om mee te werken. Als u echter een meer ervaren ontwikkelaar bent, vindt u mogelijk later meer nuttige informatie in het artikel.
Functioneel programmeren is waarschijnlijk de stijl waarmee je het meest vertrouwd bent - en bijna universeel - is de stijl die wordt gebruikt in de verschillende WordPress-website met codefragmenten die over het internet zweven. Om deze reden kan het soms worden gezien als 'instapniveau' programmeren: de stijl die door beginners wordt gebruikt totdat ze hebben geleerd objectgeoriënteerd programmeren onder de knie te krijgen. Dit is ongelooflijk misleidend, omdat functioneel programmeren veel eenvoudiger is, maar op zich niet minderwaardig.
Functioneel programmeren legt de nadruk op de evaluatie van functies en vermijdt de notie van toestanden of objecten in tegenstelling tot objectgeoriënteerd programmeren, hetgeen het denken over code als handelen op object (en) aanmoedigt, werkwijzen gebruikt om die objecten te veranderen of ermee te werken. Laten we eens kijken naar een heel eenvoudig exemplaar dat de twee stijlen met elkaar vergelijkt:
// Functionele methode functie add_two ($ n) return $ n +2; $ a = 2; $ b = add_two ($ a); // $ b = 4; // Object georiënteerde methode klasse Number var $ value = 0; function __construct ($ a) $ this-> waarde = $ a; function add_two () $ this-> value = $ this-> waarde +2; $ a = nieuw nummer (2); echo $ a-> waarde; // Drukt 2 $ a-> add_two () af; echo $ a-> waarde; // Afdrukken 4
Dit zeer eenvoudige voorbeeld illustreert het fundamentele verschil in stijl van de twee paradigma's: functioneel programmeren richt zich op het doorgeven van argumenten aan en het ontvangen van waarden uit functies. Er zijn geen 'objecten' waarop wordt gehandeld, alleen parameters en retourwaarden. Omgekeerd wijst de objectgerichte benadering een object verschillende eigenschappen toe (in ons geval een 'waarde') en werken methoden op die eigenschappen.
Het definiëren van functies is heel eenvoudig:
functie toevoegen ($ nummer, $ nummer2 = 1) // Voer code uit die werkt op doorgegeven variabelen $ sum = $ nummer + $ nummer2; // Optioneel, indien nodig kunt u een value return $ sum retourneren;
Nadat de functie is gedeclareerd, kan deze overal in uw plug-in worden gebruikt. Met andere woorden: deze heeft een wereldwijd bereik.
$ a = 4; $ b = 7; echo toevoegen ($ a, $ b); // Afdrukken 11Functies moeten unieke namen hebben. Een nieuwe functie declareren zal een fout veroorzaken. Aangezien uw code naast andere plug-ins, thema's en WordPress zelf wordt uitgevoerd, mag u nooit generieke namen gebruiken. In plaats daarvan moet u uw functienamen prefixen met iets unieks (zoals de naam van uw plug-in).
Je hebt misschien gemerkt dat in de definitie van toevoegen, het tweede argument is gelijk aan 1. Hiermee stelt u een standaardwaarde in voor $ number2 (in dit geval, 1), en daarmee het argument optioneel maken. Als het argument niet wordt opgegeven, wordt de waarde als standaardwaarde beschouwd:
echo toevoegen (4); // Drukt 5 echo-add (4, 1) af; // Afdrukken 5
Aan de andere kant is er geen standaardwaarde voor de eerste waarde, dus als u dit argument weglaat, wordt er een fout gegenereerd
echo add (); // Gooit een fout omdat $ -nummer niet is gedefinieerd
U kunt ook een variabel aantal argumenten hebben. Binnen de functie die we kunnen gebruiken func_num_args () om het aantal ontvangen argumenten te krijgen, terwijl func_get_arg () geeft u toegang tot een bepaalde doorgegeven variabele, geïndexeerd vanaf 0.
function sum () // Verkrijg het aantal argumenten gegeven aan sum () $ number_args = func_num_args (); $ sum = 0; als (! $ number_args) $ sum retourneert; voor ($ 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
Het bovenstaande kan ook in objectmethoden worden gebruikt. Tenslotte, door een variabele als 'globaal' te declareren, hebt u toegang tot de variabele vanuit een functie.
$ a = 'Hallo'; $ b = 'Wereld'; function hello_world () // Dit is nodig om toegang te krijgen tot $ a en $ b // buiten het bereik van de functie. globale $ a, $ b; $ b = $ a. ". $ b; hello_world (); echo $ b; // Print 'Hello World'Het gebruik van globals wordt over het algemeen afgeraden. Vooral omdat twee plug-ins die dezelfde naam gebruiken voor een globale variabele ervoor kunnen zorgen dat een of beide plug-ins kunnen breken. Als u een globale variabele moet gebruiken, zorg er dan voor dat deze uniek is door voor de naam van uw plug-in te kiezen.
Bepalen welke programmeerstijl moet worden gebruikt, hangt af van het oordeel - en ja - persoonlijke voorkeur. Het is niet meer goed of fout om functioneel dan objectgeoriënteerd programmeren te gebruiken, maar vaker wel dan niet is er één stijl die beter geschikt is voor wat je probeert te bereiken.
Soms is objectgeoriënteerd programmeren eenvoudigweg niet noodzakelijk, en alleen over compliceert het zaken, of introduceert overtollige code. Een voorbeeld kunnen de verschillende 'utility'-functies zijn die WordPress biedt. Dit zijn generieke functies die dienen om een bepaald doel te bereiken. Bijvoorbeeld wp_trim_words ($ text, $ num_words) eenvoudig de gegeven string op een bepaalde grootte (in woorden). Het zou niets toevoegen om te definiëren wp_trim_words () in plaats daarvan als een methode die bij een object hoort en zou resulteren in lelijkere code. Bij functioneel programmeren is één regel nodig.
Een voordeel van functioneel programmeren, vooral voor beginners, is de eenvoud. U hoeft zich geen zorgen te maken over statische, privé- of beschermde functies - ze zijn allemaal wereldwijd. Evenmin bestaat het begrip statische variabelen. Op het basisniveau retourneert uw functie een uitvoer die is afgeleid van wat u eraan hebt gegeven. Bijvoorbeeld, get_the_title (7) zal de titel voor het bericht met ID 7 retourneren.
Een ander voordeel van functioneel programmeren is dat functies wereldwijd toegankelijk zijn. Om object-georiënteerde programma's te gebruiken, om op een specifiek object in te werken, moet je dat object omgeven. Dit kan soms lastig zijn. Om dit te illustreren, nemen we een voorbeeld uit deel een:
Accentsconagua
class DemoPlugin public function __construct () add_action ('wp_enqueue_scripts', array ($ this, 'register_plugin_scripts')); public function register_plugin_scripts () // Register-pluginscripts $ demo_plugin = nieuwe DemoPlugin (); Wanneer WordPress de register_plugin_scripts () methode zodat deze kan worden aangeroepen wanneer de wp_enqueue_scripts actie wordt getriggerd door naar niet alleen de methode, maar ook het object te verwijzen $ demo_plugin. Dit komt omdat dezelfde methode voor verschillende exemplaren van een object wordt beschouwd verschillend methoden - dat wil zeggen, $ Demo_plugin-> register_plugin_scripts () en $ Copy_of_demo_plugin-> register_plugin_scripts () zijn niet hetzelfde. Dit lijkt misschien raar - maar methoden kunnen zich anders gedragen voor verschillende instanties van dezelfde klasse, dus we moeten verwijzen naar zowel de methode als het exemplaar.
Maar waarom doet dit ertoe? Het maakt het erg moeilijk voor een externe plug-in of een ander thema om die methode los te koppelen, omdat ze daarvoor moeten bellen:
remove_action ('wp_enqueue_scripts', array ($ demo_plugin, 'register_plugin_scripts')); Maar over het algemeen hebben ze geen toegang tot de $ demo_plugin variabel. (Opmerking: als de methode statisch is verklaard, kunt u deze omzeilen).
Natuurlijk heeft objectgeoriënteerd programmeren zijn voordelen, zoals besproken in deel één. Zoals Tom ook al zei, is het onvermijdelijk bij het gebruik van WordPress widget-API. Een ander bekend voorbeeld is WP_Query (). Hier is een objectgerichte benadering duidelijk de beste: je hebt een object (in dit geval een query), dat verschillende eigenschappen heeft (dwz zoekcriteria, paginatie-informatie, overeenkomende resultaten) en je wilt handelen in die query (ontleden, genereren en reinig de bijbehorende SQL en retourneer de resultaten).
WP_Query () laat zien hoe krachtig objectgeoriënteerd programmeren kan zijn bij correct gebruik. Na het starten van de query:
$ the_query = new WP_Query (array (...));
U hebt niet alleen toegang tot de resultaten, maar ook tot andere informatie, zoals pagineringswaarden: hoeveel pagina's met resultaten er zijn, welke pagina wordt bekeken, het totale aantal resultaten en het type query, bijvoorbeeld. $ The_query-> is_search (), $ The_query-> is_single () etc. Er is ook de volledige 'loop'-infrastructuur;
if ($ the_query-> have_posts ()) echo '
Dat verbergt alle interne jongleren van resultaten en globalen achter een mensvriendelijke API.
Dus hoe zit het met get_posts ()? Dit dient gewoon als een verpakking voor WP_Query (), en retourneert eenvoudig een reeks berichten die overeenkomen met de query. Als zodanig krijg je niet de 'toeters en bellen' van WP_Query (), maar het is iets efficiënter. Dus of je moet gebruiken get_posts () of WP_Query () hangt af van uw gebruik (bijvoorbeeld of u paginering nodig heeft of niet), maar het is ook afhankelijk van uw persoonlijke voorkeur.
$ results = get_posts (array (...)); if ($ resultaten) echo '
Hopelijk hebben deze twee artikelen geholpen de voor- en nadelen van deze programmeerstijlen te benadrukken. Het take-away punt is dat hier geen goed en fout is en dat elke programmeur zijn eigen persoonlijke voorkeur zal hebben. Maar sommige contexten lenen zich eerder voor een bepaalde programmeerstijl - en als zodanig moet je verwachten dat je plug-in een combinatie van beide bevat.
