Singletons i WordPress, Revisited (en tid och en plats?)
Innan jag börjar ett inlägg där jag pratar om att använda singletons i WordPress (eller, mer lämpligt, Singleton Pattern ), vill jag se till att du läser följande två artiklar:
- Kloning i PHP, eller varför din singleton kan döda WordPress av Thomas Scholz
- Singletons och deras användning i WordPress av Carl Alexander
Båda dessa artiklar ger ett oerhört värdefullt perspektiv på detta mönster och farorna med att använda det när du använder det under hela vårt arbete i WordPress; Men betyder det att vi helt bör undvika dem?
Jag tror inte det.
Återigen, jag inser också att artiklarna inte säger att man helt ska undvika dem. De ger starka argument för hur man använder dem och farorna med att använda dem om du väljer att göra det.
Och även om jag definitivt har använt dem tidigare, har jag i allmänhet slutat. Men jag stötte nyligen på ett användningsfall för ett projekt där jag tycker att det är acceptabelt.
Använder du fortfarande Singletons i WordPress?
För att ge en anledning till varför jag ens överväger just detta mönster, tycker jag att det är värt att först förstå användningsfallet. För att uttrycka sig enkelt:
- Det finns en administrationssida som låter användaren välja hur de vill visa datumen på sidans front-end.
- När användaren sparar alternativet kommer den att skriva det PHP-baserade formatet för datumet till en tabell i WordPress.
- När du renderar ett datum kommer värdet att hämtas från databasen och tillämpas på det datum som ska renderas.
Och för de som är nyfikna finns det bara en handfull – säg fyra eller fem – sätt som vi tillåter användaren att visa datumet på.
Eftersom det här speciella projektet tillåter användare att importera CSV:er av data (som inkluderar datum) och som tillåter dem att rendera data från CSV:erna om än i ett annat format, är det värt att notera att det finns en hel del datumformatering på baksidan.
Naturligtvis uppstår en fråga:
Varför inte bara formatera datumet när användaren importerar sin CSV?
Och det beror på att användaren kan välja att ändra hur datumet renderas efter att CSV-filen har importerats.
Med det sagt, det finns en helt annan mekanism i pluginet som är ansvarig för att validera, sanera och skriva användarindata till databasen.
Men när det är dags att ta tag i värden från databasen, särskilt när det kommer i form av att läsa ett värde från en databastabell, och göra det på flera punkter i hela applikationen, vore det inte vettigt att ha en enda punkt från vilket värde kan härledas?
En titt på hög nivå på hur detta fungerar.
Eller, ett annat sätt att uttrycka det, är det inte meningsfullt att ändra en plats i applikationen som lätt kan överlappa resten av applikationen istället för att söka efter alla möjliga platser för:
- läser alternativet,
- se till att den är inställd,
- definiera en standard om den inte är inställd,
- och returnera värdet?
Och det är här jag ser en giltig användning av en singleton i WordPress komma in i bilden: Ett sätt att läsa data på flera punkter i hela applikationen. Detta medför dock vissa implikationer:
- klassen behöver inte instansieras mer än en gång (jag menar, det är hela idén med singletonen),
- det kommer inte att hantera föränderlig data,
- det kommer inte att vara att skriva information eller manipulera information.
Med andra ord, det är ensamt ansvarigt för att hämta information och returnera den. Det är allt. Inget annat.
Ett exempel på implementering
Så hur kan det här se ut? Här är en grov implementering för samtalets syfte:
<?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;
}
}
Som du kan se uppfyller den alla punkter ovan. Det vill säga, den läser data, ställer in ett standardvärde och returnerar det sedan.
Den här klassen gör inget annat än att läsa och returnera en mycket specifik uppsättning data.
En varning om cachelagring
Uppenbarligen, eftersom den här klassen läser data från databasen, kan den cachelagras – och eventuellt bör den. Meningen med det här inlägget är dock inte att komma in på transienter, utgångsdatum och att arbeta igenom alla dessa nyanser.
Istället handlar det om att utvärdera om detta är ett giltigt användningsfall för att implementera en singleton i WordPress.
Vänta, det behöver inte vara så här!
Jag vet jag vet. Psyk! Jag tror att det är den korrekta terminologin, men låt oss hålla detta professionellt.
Fram till denna punkt pratade hela inlägget om varför du kanske vill undersöka att använda singletons i WordPress så att du har ett sätt att enkelt hämta information med konsekventa objektorienterade principer.
Men jag tror fortfarande inte att det är nödvändigt att använda en singleton i WordPress här. Åtminstone tycker jag att en statisk funktion är bra. Och den enda anledningen till att jag tycker att det är okej är att skapa en instans av klassen varje gång du behöver komma åt en funktion som hämtar data som inte kommer att förändras inom klassen är överdrivet.
Så hur ser det här ut?
<?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;
}
}
Och det tror jag är en bättre lösning än att implementera ett godtyckligt designmönster när det inte behövs alls.
Men jag är öppen för att bli övertygad om något annat.
Tankar från mer erfarna utvecklare?
Jag har hört från en vän och kamrat än att bara använda en namnavgränsad funktion kan till och med vara rätt väg att gå. Det är uppenbart att det finns en mängd olika sätt att tackla detta.
Och med det är jag intresserad av att höra från er andra om hur ni kan refaktorera detta ytterligare. Jag är inte så mycket bekymrad över implementeringen av get -funktionen eftersom den huvudsakligen är sammansatt för demon.
Istället är jag intresserad av sätt att hantera detta utanför det som presenteras här. Eller snarare, bara din syn på det du ser.