Ennen kuin aloitan postauksen, jossa puhutaan singletonien käytöstä WordPressissä (tai sopivammin Singleton Pattern ), haluan varmistaa, että luet seuraavat kaksi artikkelia:
- Kloonaus PHP:ssä tai miksi sinkkusi saattaa tappaa WordPressin, kirjoittanut Thomas Scholz
- Singletonit ja niiden käyttö WordPressissä Carl Alexander
Molemmat artikkelit tarjoavat äärimmäisen arvokkaan näkökulman tähän malliin ja sen käytön vaaroihin, kun käytät sitä WordPress-työssämme. tarkoittaako se kuitenkin, että meidän pitäisi välttää niitä kokonaan?
En usko niin.
Ymmärrän myös, että artikkeleissa ei ole tarkoitus välttää niitä kokonaan. He antavat vahvoja perusteita niiden käyttöön ja niiden käytön vaaroista, jos päätät tehdä niin.
Ja vaikka olen ehdottomasti käyttänyt niitä aiemmin, olen yleensä lopettanut. Törmäsin kuitenkin äskettäin käyttötapaukseen projektille, jossa se on mielestäni hyväksyttävää.
Käytätkö edelleen Singletoneja WordPressissä?
Jotta voisin antaa syyn sille, miksi edes harkitsen tätä mallia, mielestäni kannattaa ensin ymmärtää käyttötapaus. Yksinkertaisesti:
- Siellä on hallintasivu, jonka avulla käyttäjä voi valita, kuinka hän haluaa näyttää päivämäärät sivuston etuosassa.
- Kun käyttäjä tallentaa vaihtoehdon, se kirjoittaa päivämäärän PHP-pohjaisen muodon WordPressin taulukkoon.
- Päivämäärää hahmonnettaessa arvo noudetaan tietokannasta ja sitä sovelletaan hahmonnettavaan päivämäärään.
Ja niille, jotka ovat uteliaita, on olemassa vain kourallinen – vaikkapa neljä tai viisi – tapaa, joilla annamme käyttäjän näyttää päivämäärän.
Koska tämän projektin avulla käyttäjät voivat tuoda tietoja CSV-tiedostoina (joissa on päivämäärät) ja joiden avulla he voivat renderöidä tietoja CSV-tiedostoista, vaikkakin eri muodossa, on syytä huomata, että taustalla tapahtuu melko paljon päivämäärän muotoilua.
Luonnollisesti herää kysymys:
Mikset vain muotoile päivämäärää, kun käyttäjä tuo CSV-tiedoston?
Tämä johtuu siitä, että käyttäjä voi halutessaan muuttaa päivämäärän esitystapaa CSV-tiedoston tuonnin jälkeen.
Tästä huolimatta laajennuksessa on tämä kokonaan toinen mekanismi, joka vastaa käyttäjän syötteiden vahvistamisesta, puhdistamisesta ja kirjoittamisesta tietokantaan.
Mutta kun on aika noutaa arvot tietokannasta, varsinkin kun kyse on arvon lukemisesta tietokantataulukosta, ja tehdä niin useissa kohdissa koko sovelluksen, eikö olisi järkevää saada yksi piste jonka arvo voidaan johtaa?
Korkean tason katsaus miten tämä toimii.
Tai toinen tapa ilmaista se, eikö ole järkevää vaihtaa yhtä paikkaa sovelluksessa, joka voi helposti ketjuttaa koko muun sovelluksen sen sijaan, että etsittäisiin kaikkia mahdollisia paikkoja:
- lue vaihtoehto,
- varmista, että se on asetettu,
- oletusarvon määrittäminen, jos sitä ei ole asetettu,
- ja arvon palauttaminen?
Ja tässä näen yhden sanan oikean käytön WordPressissä tulevan peliin: tapa lukea tietoja useista kohdista koko sovelluksessa. Tähän liittyy kuitenkin joitain seurauksia:
- luokkaa ei tarvitse ilmentää useammin kuin kerran (tarkoitan, että se on singletonin koko idea),
- se ei käsittele muuttuvaa dataa,
- se ei kirjoita tietoja tai manipuloi tietoja.
Toisin sanoen se on yksin vastuussa tietojen hakemisesta ja palauttamisesta. Se siitä. Ei mitään muuta.
Esimerkkitoteutus
Miltä tämä sitten mahtaa näyttää? Tässä on karkea toteutus keskustelua varten:
<?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;
}
}
Kuten näet, se täyttää kaikki yllä olevat kohdat. Eli se lukee tiedot, asettaa oletusarvon ja palauttaa sen sitten.
Tämä luokka ei tee mitään muuta kuin lukee ja palauttaa erittäin tarkan tietojoukon.
Varoitus välimuistiin tallentamisesta
On selvää, että koska tämä luokka lukee tietoja tietokannasta, se voidaan – ja mahdollisesti pitäisi – tallentaa välimuistiin. Tämän postauksen tarkoitus ei kuitenkaan ole puuttua transienteihin, vanhenemiseen ja kaikkien näiden vivahteiden läpikäymiseen.
Sen sijaan kyse on arvioinnista, onko tämä pätevä käyttötapa singletonin käyttöönottamiseksi WordPressissä.
Odota, sen ei tarvitse olla näin!
Tiedän tiedän. Psyykki! Uskon, että se on oikea terminologia, mutta pidetään tämä ammattimaisena.
Tähän asti koko viesti puhui siitä, miksi saatat haluta tutkia singletonien käyttöä WordPressissä, jotta sinulla on tapa helposti noutaa tietoja johdonmukaisesti oliopohjaisilla periaatteilla.
Mutta en silti usko, että singletonin käyttäminen WordPressissä on välttämätöntä. Ainakin staattinen toiminto on mielestäni hyvä. Ja ainoa syy mielestäni on okei, koska luokan esiintymän luominen joka kerta, kun sinun on käytettävä toimintoa, joka hakee tietoja, jotka eivät muutu luokassa, on ylivoimaista.
Joten miltä tämä näyttää?
<?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 se on mielestäni parempi ratkaisu kuin mielivaltaisen suunnittelumallin toteuttaminen, kun sitä ei ollenkaan tarvita.
Mutta olen valmis vakuuttumaan toisin.
Kokeneempien kehittäjien ajatuksia?
Olen kuullut kollegaltani ja kollegoiltani, että pelkkä nimiavaruustoiminnon käyttäminen saattaa jopa olla oikea tapa edetä. On selvää, että tähän on olemassa useita tapoja ratkaista.
Ja sen myötä olen kiinnostunut kuulemaan teiltä muilta, kuinka voit muuttaa tätä entisestään. En ole niin kiinnostunut get – toiminnon toteuttamisesta, koska se on koottu pääasiassa demoa varten.
Sen sijaan olen kiinnostunut tavoista käsitellä tätä tässä esitetyn ulkopuolella. Tai pikemminkin vain oma näkemyksesi näkemästäsi.