Enne kui alustan postitust, mis räägib üksiktoonide kasutamisest WordPressis (või õigemini Singleton Pattern ), tahan kindlasti lugeda läbi järgmised kaks artiklit:
- Kloonimine PHP-s või miks teie üksikmees võib WordPressi tappa, autor Thomas Scholz
- Singletonid ja nende kasutamine WordPressis Carl Alexander
Mõlemad artiklid pakuvad selle mustri ja selle kasutamise ohtude kohta tohutult väärtuslikku vaatenurka meie WordPressis töötades. aga kas see tähendab, et peaksime neid täielikult vältima?
Ma ei usu.
Samas mõistan ka, et artiklites ei ole öeldud, et neid tuleks täielikult vältida. Nad annavad selgeid põhjendusi nende kasutamiseks ja nende kasutamise ohtudest, kui otsustate seda teha.
Ja kuigi ma olen neid kindlasti varem kasutanud, olen üldiselt lõpetanud. Siiski leidsin hiljuti ühe projekti kasutusjuhtumi, mille puhul ma arvan, et see on vastuvõetav.
Kas kasutate endiselt WordPressis Singletone?
Et anda põhjust, miks ma seda konkreetset mustrit üldse kaalun, arvan, et kõigepealt tasub mõista kasutusjuhtu. Lihtsamalt öeldes:
- Seal on haldusleht, mis võimaldab kasutajal valida, kuidas ta soovib saidi esiküljel kuupäevi kuvada.
- Kui kasutaja suvandi salvestab, kirjutab ta WordPressi tabelisse kuupäeva PHP-põhise vormingu.
- Kuupäeva renderdamisel hangitakse väärtus andmebaasist ja rakendatakse renderdatavale kuupäevale.
Ja neile, kes on uudishimulikud, on ainult käputäis – näiteks neli või viis – viisi, kuidas me lubame kasutajal kuupäeva kuvada.
Kuna see konkreetne projekt võimaldab kasutajatel importida andmete CSV-sid (mis sisaldavad kuupäevi) ja võimaldab neil CSV-dest andmeid renderdada, ehkki erinevas vormingus, tasub märkida, et taustal toimub üsna palju kuupäeva vormindamist.
Loomulikult tekib küsimus:
Miks mitte lihtsalt vormindada kuupäev, mil kasutaja oma CSV-faili impordib?
Ja seda seetõttu, et kasutaja võib pärast CSV-faili importimist muuta kuupäeva renderdamise viisi.
Sellega seoses on pistikprogrammis see täiesti teine mehhanism, mis vastutab kasutaja sisendi andmebaasi valideerimise, puhastamise ja kirjutamise eest.
Kui aga tuleb aeg hankida väärtusi andmebaasist, eriti kui tegemist on väärtuste lugemisega andmebaasi tabelist ja tehes seda mitmes punktis kogu rakenduses, siis kas poleks mõttekas omada ühte punkti mille väärtuse saab tuletada?
Kõrgetasemeline ülevaade selle toimimisest.
Või poleks mõttekas muuta rakenduses ühte kohta, mis võib hõlpsasti kogu ülejäänud rakenduse kaskaadida, selle asemel et otsida kõiki võimalikke kohti:
- valiku lugemine,
- veendudes, et see on seadistatud,
- vaikeväärtuse määramine, kui see pole määratud,
- ja väärtuse tagastamine?
Ja see on koht, kus ma näen, et WordPressis hakkab mängu tulema üksikute sõnade õige kasutamine: viis andmete lugemiseks rakenduse mitmes punktis. Sellel on siiski mõned tagajärjed:
- klassi ei pea instantseerima rohkem kui üks kord (ma mõtlen, et see on kogu üksikisiku idee),
- see ei tegele muutuvate andmetega,
- see ei kirjuta teavet ega manipuleeri teabega.
Teisisõnu vastutab ta ainuisikuliselt teabe hankimise ja tagastamise eest. See on kõik. Mitte midagi muud.
Rakenduse näide
Kuidas see siis välja näha võib? Siin on vestluse jaoks ligikaudne teostus :
<?php
class Date_Formatter {
private static $instance;
private function __construct() {
}
private static function get_instance() {
if (null === self::$instance) {
self::$instance = new self;
}
return self::$instance;
}
public static function get() {
self::get_instance();
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Nagu näete, täidab see kõik ülaltoodud punktid. See tähendab, et see loeb andmeid, määrab vaikeväärtuse ja tagastab selle.
See klass ei tee muud, kui loeb ja tagastab väga spetsiifilise andmekogumi.
Hoiatus vahemällu salvestamise kohta
Ilmselgelt, kuna see klass loeb andmeid andmebaasist, saab selle vahemällu salvestada – ja võib-olla peaks see olema. Selle postituse mõte ei ole aga sattuda mööduvatesse sündmustesse, aegumistesse ja kõigi nende nüansside läbi töötamisse.
Selle asemel on vaja hinnata, kas see on WordPressis üksiku elemendi juurutamiseks sobiv kasutusjuht või mitte.
Oota, see ei pea nii olema!
Ma tean, ma tean. Psühh! Usun, et see on õige terminoloogia, kuid jätkem see professionaalseks.
Kuni selle hetkeni rääkis kogu postitus sellest, miks võiksite uurida üksiktoonide kasutamist WordPressis, et saaksite hõlpsasti teavet hankida, kasutades järjekindlalt objektorienteeritud põhimõtteid.
Kuid ma siiski ei arva, et siinkohal oleks vaja WordPressis üksikut kasutada. Vähemalt arvan, et staatiline funktsioon sobib hästi. Ja ainus põhjus, miks ma arvan, et see on okei, on see, et klassi eksemplari loomine iga kord, kui vajate juurdepääsu funktsioonile, mis hangib andmeid, mis klassi sees ei muutu, on liigne.
Kuidas see siis välja näeb?
<?php
class Date_Formatter {
public static function get() {
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Ja see on minu arvates parem lahendus kui suvalise kujundusmustri rakendamine, kui seda pole üldse vaja.
Kuid ma olen valmis veenduma vastupidises.
Kogenumate arendajate mõtted?
Olen kuulnud kaassõbralt ja eakaaslaselt, et lihtsalt nimeruumi funktsiooni kasutamine võib isegi olla õige tee. On selge, et selle probleemi lahendamiseks on erinevaid viise.
Sellega seoses on mul huvi kuulda teistelt, kuidas saaksite seda veelgi enam ümber kujundada. Ma ei muretse nii palju funktsiooni hankimise pärast, kuna see on peamiselt demo jaoks kokku pandud.
Selle asemel huvitab mind viise, kuidas sellega toime tulla väljaspool siin esitatut. Või õigemini lihtsalt teie ettekujutus sellest, mida näete.