W projekcie PHP, jakie wzorce istnieją do przechowywania, dostępu i organizowania obiektów pomocniczych? [zamknięte]

class Application {
    protected static $_singletonFoo=NULL;

    public static function foo() {
        if(NULL === self::$_singletonFoo) {
            self::$_singletonFoo = new Foo;
        }
        return self::$_singletonFoo;
    }

}

Application::foo()->bar();

To sposób, w jaki to robię, szanuje zasady OOP,jest mniej kodu niż to, co robisz teraz, a obiekt jest tworzony tylko wtedy, gdy kod potrzebuje go po raz pierwszy.

Uwaga: to, co przedstawiłem, nie jest nawet prawdziwym wzorem Singletona. Singleton pozwala tylko na jedną instancję, definiując konstruktor (Foo::_ _ constructor ()) jako prywatny. To tylko " globalny" zmienna dostępna dla wszystkich instancji "aplikacji". Dlatego uważam, że jego użycie jest ważne, ponieważ nie lekceważy dobrych zasad OOP. Oczywiście, jak cokolwiek na świecie, ten "wzór" nie powinien być nadużywany!

Widziałem, że jest to używane w wielu frameworkach PHP, Zend Framework i Yii. I powinieneś użyć frameworka. Nie powiem ci, który.

Dodatek Dla tych spośród was, którzy martwią się o TDD, możecie jeszcze nadrobić trochę okablowanie do dependency-inject it. Może to wyglądać tak:

class Application {
        protected static $_singletonFoo=NULL;
        protected static $_helperName = 'Foo';

        public static function setDefaultHelperName($helperName='Foo') {
                if(is_string($helperName)) {
                        self::$_helperName = $helperName;
                }
                elseif(is_object($helperName)) {
                        self::$_singletonFoo = $helperName;
                }
                else {
                        return FALSE;
                }
                return TRUE;
        }
        public static function foo() {
                if(NULL === self::$_singletonFoo) {
                        self::$_singletonFoo = new self::$_helperName;
                }
                return self::$_singletonFoo;
        }
}

Dlaczego tak to robisz? Cóż, przez większość czasu aplikacja nie będzie testowana jednostkowo, będzie uruchamiana, , miejmy nadzieję, że w środowisku produkcyjnym. Siłą PHP jest jego szybkość. PHP nie jest i nigdy nie będzie "czystym językiem OOP", jak Java.

Wewnątrz aplikacji istnieje tylko jedna klasa aplikacji i tylko jedna instancja każdego z jego pomocników, co najwyżej (jak na leniwe ładowanie jak powyżej). Jasne, singletony są złe, ale z drugiej strony, tylko jeśli nie przylegają do prawdziwego świata. w moim przykładzie tak.

Stereotypowe "zasady", takie jak "singletony są złe", są źródłem zła, są dla leniwych ludzi, którzy nie chcą myśleć za siebie.

Tak, wiem, Manifest PHP jest zły, technicznie rzecz biorąc. Jednak jest to język udany, w swoim hackish sposób.

Dodatek

Jeden styl funkcji:

function app($class) {
    static $refs = array();

    //> Dependency injection in case of unit test
    if (is_object($class)) {
        $refs[get_class($class)] = $class;
        $class = get_class($class);
    }

    if (!isset($refs[$class]))
        $refs[$class] = new $class();

    return $refs[$class];
}

//> usage: app('Logger')->doWhatever();

Podoba mi się pojęcie iniekcji zależności:

"Dependency Injection to miejsce, w którym komponenty otrzymują swoje zależności za pomocą konstruktorów, metod lub bezpośrednio do pól. (From Pico Container Website)"

Fabien Potenier napisał naprawdę ładną serię artykułów na temat iniekcji zależności i potrzeby ich użycia. Oferuje również ładny i mały pojemnik do wstrzykiwania zależności o nazwie Pimple , z którego bardzo lubię korzystać (więcej informacji na github ).

Jak wspomniano powyżej, nie podoba mi się używanie singletonów. Dobre podsumowanie dlaczego Singletony nie są dobrym projektem można znaleźć tutaj na blogu Steve 'a Yegge' a.

Najlepszym podejściem jest posiadanie pewnego rodzaju kontenera dla tych zasobów. Niektóre z najczęstszych sposobów implementacji tego kontenera :

Singleton

Nie zaleca się, ponieważ jest trudny do przetestowania i implikuje stan globalny. (Singletonitis)

Rejestr

Eliminuje singletonitis, bug też nie polecam, bo to też rodzaj Singletona. (Trudny do jednostkowego testu)

Dziedziczenie

Szkoda, nie ma wielokrotności dziedziczenie w PHP, więc ogranicza to wszystko do łańcucha.

Dependency injection

To lepsze podejście, ale większy temat.

Tradycyjny

Najprostszym sposobem jest użycie konstruktora lub iniekcji settera (przekazać obiekt zależności za pomocą settera lub w konstruktorze klasy).

Ramy

Możesz uruchomić własny dependency injector lub użyć niektórych frameworków dependency Injector, np. Yadif

Zastosowanie resource

Możesz zainicjować każdy ze swoich zasobów w aplikacji bootstrap (która działa jak kontener) i uzyskać do nich dostęp w dowolnym miejscu w aplikacji uzyskującej dostęp do obiektu bootstrap.

Jest to podejście zaimplementowane w Zend Framework 1.x

Resource loader

Rodzaj obiektu statycznego, który ładuje (tworzy) potrzebny zasób tylko wtedy, gdy jest potrzebny. To bardzo mądre podejście. Możesz to zobaczyć w akcji np. implementacja zastrzyk zależności Symfony komponent

Wstrzyknięcie do określonej warstwy

Zasoby nie zawsze są potrzebne w dowolnym miejscu aplikacji. Czasami po prostu potrzebujesz ich np. w kontrolerach (MV C ). Następnie możesz wstrzyknąć zasoby tylko tam.

Powszechnym podejściem jest używanie komentarzy docblock do dodawania metadanych iniekcji.

Zobacz moje podejście do tego tutaj:

Jak używać dependency injection w Zend Framework? - Przepełnienie Stosu

In the end, Chciałbym tutaj dodać notatkę o bardzo ważnej rzeczy - buforowaniu.
Ogólnie rzecz biorąc, pomimo wybranej techniki, powinieneś pomyśleć, w jaki sposób zasoby będą buforowane. Pamięć podręczna będzie samym zasobem.

Aplikacje mogą być bardzo duże, a ładowanie wszystkich zasobów na każde żądanie jest bardzo kosztowne. Istnieje wiele podejść, w tym ten appserver-in-PHP - Project Hosting na Google Code.

Jeśli chcesz, aby obiekty były dostępne globalnie, wzór rejestru może być dla ciebie interesujący. Aby uzyskać inspirację, zajrzyj do Zend Registry .

Więc równieżRegistry vs. Singleton pytanie.

Obiekty w PHP zajmują sporą ilość pamięci, co zapewne widać po testach jednostkowych. Dlatego jest idealnym rozwiązaniem, aby zniszczyć niepotrzebne obiekty jak najszybciej , Aby zapisać pamięć dla innych procesów. Mając to na uwadze stwierdzam, że każdy przedmiot pasuje do jednej z dwóch form.

1) obiekt może mieć wiele użytecznych metod lub musi być wywołany więcej niż raz w tym przypadku zaimplementuję singleton / registry:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) obiekt istnieje tylko dla życia wywołanie metody/funkcji w takim przypadku proste tworzenie jest korzystne, aby zapobiec utrzymywaniu obiektów zbyt długo przy życiu.

$object = new Class();

Przechowywanie obiektów tymczasowych w dowolnym miejscu może prowadzić do wycieków pamięci, ponieważ odniesienia do nich mogą zostać zapomniane o przechowywaniu obiektu w pamięci przez resztę skryptu.

Wybrałbym funkcję zwracającą zainicjalizowane obiekty:

A('Users')->getCurrentUser();

W środowisku testowym można zdefiniować, aby zwracać makiety. Można nawet wykryć wewnątrz, kto wywołuje funkcję za pomocą debug_backtrace () i zwrócić różne obiekty. Możesz zarejestrować się w nim, kto chce uzyskać jakie obiekty, aby uzyskać wgląd w to, co tak naprawdę dzieje się w twoim programie.

Dlaczego nie przeczytać dobrego podręcznika?

Http://php.net/manual/en/language.oop5.autoload.php