✅ Nowości, motywy, wtyczki WEB i WordPress. Tutaj dzielimy się wskazówkami i najlepszymi rozwiązaniami dla stron internetowych.

Singletony w WordPressie, ponownie (czas i miejsce?)

18

Zanim zacznę post mówiący o używaniu singletonów w WordPressie (a właściwie Wzorzec Singleton ), chcę się upewnić, że przeczytałeś następujące dwa artykuły:

Oba te artykuły dostarczają niezwykle cennego spojrzenia na ten wzorzec i niebezpieczeństw związanych z jego używaniem podczas pracy z WordPressem; jednak czy to oznacza, że ​​powinniśmy ich całkowicie unikać?

Nie sądzę.

Z drugiej strony zdaję sobie sprawę, że artykuły nie mówią, aby całkowicie ich unikać. Dają mocne argumenty, jak ich używać i niebezpieczeństwa związane z ich używaniem, jeśli zdecydujesz się to zrobić.

I chociaż na pewno używałem ich w przeszłości, generalnie przestałem. Jednak ostatnio natknąłem się na przypadek użycia dla projektu, w którym uważam, że jest to dopuszczalne.

Nadal używasz singletonów w WordPressie?

Aby dać powód, dla którego w ogóle rozważam ten konkretny wzorzec, myślę, że warto najpierw zrozumieć przypadek użycia. Mówiąc prościej:

  • Istnieje strona administracyjna, która pozwala użytkownikowi wybrać sposób wyświetlania dat na interfejsie witryny.
  • Gdy użytkownik zapisze opcję, zapisze format daty oparty na PHP do tabeli w WordPress.
  • Podczas renderowania daty wartość zostanie pobrana z bazy danych i zastosowana do daty, która ma być renderowana.

A dla tych, którzy są ciekawi, istnieje tylko kilka – powiedzmy cztery lub pięć – sposobów, na które pozwalamy użytkownikowi wyświetlić datę.

Ponieważ ten konkretny projekt umożliwia użytkownikom importowanie plików CSV z danymi (zawierających daty) i renderowanie danych z plików CSV, choć w innym formacie, warto zauważyć, że na zapleczu występuje spora ilość formatowania daty.

Naturalnie pojawia się pytanie:

Dlaczego po prostu nie sformatować daty importu pliku CSV przez użytkownika?

A to dlatego, że użytkownik może zdecydować się na zmianę sposobu renderowania daty po zaimportowaniu pliku CSV.

Mając to na uwadze, we wtyczce znajduje się cały inny mechanizm odpowiedzialny za walidację, oczyszczanie i zapisywanie danych wejściowych użytkownika do bazy danych.

Ale kiedy przychodzi czas na pobieranie wartości z bazy danych, zwłaszcza gdy jest to odczytywanie wartości z tabeli bazy danych i robienie tego w wielu punktach w aplikacji, nie ma sensu posiadanie jednego punktu z jaką wartość można wyprowadzić?

Ogólne spojrzenie na to, jak to działa.

Lub, inaczej mówiąc, nie ma sensu zmieniać jednego miejsca w aplikacji, które może łatwo przechodzić kaskadowo przez resztę aplikacji, zamiast szukać wszystkich możliwych miejsc:

  1. przeczytanie opcji,
  2. upewniając się, że jest ustawiony,
  3. zdefiniowanie domyślnego, jeśli nie jest ustawione,
  4. i zwracasz wartość?

I tutaj widzę prawidłowe użycie singletona w WordPressie: sposób na odczytywanie danych w wielu punktach w całej aplikacji. Wiąże się to jednak z pewnymi implikacjami:

  • klasa nie musi być tworzona więcej niż raz (to znaczy, to cała idea singletona),
  • nie będzie zajmować się zmiennymi danymi,
  • nie będzie pisać informacji ani manipulować informacjami.

Innymi słowy, ponosi wyłączną odpowiedzialność za pobieranie informacji i ich zwracanie. Otóż ​​to. Nic więcej.

Przykładowa implementacja

Więc jak to może wyglądać? Oto przybliżona implementacja na potrzeby konwersacji:

<?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;
    }
}

Jak widać, spełnia wszystkie powyższe punkty. Oznacza to, że odczytuje dane, ustawia wartość domyślną, a następnie zwraca ją.

Ta klasa nie robi nic poza odczytywaniem i zwracaniem bardzo konkretnego zestawu danych.

Zastrzeżenie dotyczące buforowania

Oczywiście, ponieważ ta klasa odczytuje dane z bazy danych, może być – i ewentualnie powinna być – zbuforowana. Celem tego postu nie jest jednak wchodzenie w stan przejściowy, wygaśnięcie i przepracowanie wszystkich tych niuansów.

Zamiast tego chodzi o ocenę, czy jest to prawidłowy przypadek użycia do implementacji singletona w WordPress.

Czekaj, nie musi tak być!

Wiem wiem. Psychika! Uważam, że to poprawna terminologia, ale zachowajmy profesjonalizm.

Do tego momentu cały post mówił o tym, dlaczego możesz chcieć zbadać użycie singletonów w WordPressie, aby mieć sposób na łatwe pobieranie informacji przy użyciu konsekwentnie zorientowanych obiektowo zasad.

Ale nadal nie uważam, że używanie singletona w WordPressie jest tutaj konieczne. Przynajmniej myślę, że funkcja statyczna jest w porządku. A jedynym powodem, dla którego uważam, że to jest w porządku, jest to, że tworzenie instancji klasy za każdym razem, gdy potrzebujesz dostępu do funkcji, która pobiera dane, które nie będą zmieniane w ramach klasy, jest przesadą.

Więc jak to wygląda?

<?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;
    }
}

A to, jak sądzę, jest lepszym rozwiązaniem niż implementacja dowolnego wzorca projektowego, gdy nie jest on w ogóle potrzebny.

Ale jestem otwarty na przekonanie, że jest inaczej.

Myśli od bardziej doświadczonych programistów?

Słyszałem od znajomego przyjaciela i współpracownika, że ​​zwykłe użycie funkcji z przestrzenią nazw może być nawet dobrym rozwiązaniem. Oczywiście istnieje wiele sposobów radzenia sobie z tym problemem.

I z tym chciałbym usłyszeć od reszty z was, w jaki sposób można to jeszcze bardziej skorygować. Nie jestem tak bardzo zainteresowany implementacją  funkcji get, ponieważ jest ona tworzona głównie na potrzeby demonstracji.

Zamiast tego interesują mnie sposoby radzenia sobie z tym poza tym, co zostało tutaj przedstawione. Albo raczej po prostu twoje podejście do tego, co widzisz.

Źródło nagrywania: tommcfarlin.com

Ta strona korzysta z plików cookie, aby poprawić Twoje wrażenia. Zakładamy, że nie masz nic przeciwko, ale możesz zrezygnować, jeśli chcesz. Akceptuję Więcej szczegółów