Jak uniknąć zderzeń z cechami PHP używanymi do iniekcji zależności

Question

W końcu wracam do odkrywania cech w PHP. Pierwsze miejsce, w którym myślałem, że wypróbuję to wtrysk bitów konfiguracyjnych na klasy. Jeśli używam DIC, może mam kod jak to w każdej klasie, która potrzebuje obiekt config:

protected function SetConfig($config) { 
    $this->config = $config; 
} 

protected $config; 

Wydaje się to naturalne dopasowanie do cech, aby uniknąć konieczności ten kod szablonowe wszędzie, więc może tworzyć w ten sposób:

trait Config { 
    protected function SetConfig($config) { 
     $this->config = $config; 
    } 

    protected $config; 
} 

a następnie używać go tak:

class Foo { 
    use Config; 

    public function __construct() { 
     //can now use $this->config 
    } 
} 

to świetnie. Teraz załóżmy, że chcę utworzyć drugą cechę, powiedzmy, do logowania:

trait Logger { 
    protected function SetLogger($logger) { 
     $this->logger = $logger; 
    } 

    protected $logger; 
} 

której mogę użyć takiego:

class Foo { 
    use Logger; 

    public function __construct() { 
     //can now use $this->logger 
    } 
} 

również wspaniałe. Teraz problem pojawia się, jeśli te dwie cechy chcą się nawzajem wykorzystać. Wydaje się całkiem rozsądne, że klasa rejestrator musiałaby mieć obiekt config wstrzykiwany, co oznacza ten sposób:

trait Logger { 
    use Config; 

    protected function SetLogger($logger) { 
     $this->logger = $logger; 
    } 

    protected $logger; 
} 

Ale potem wszystko pęknie, gdy inna klasa używa obu tych cech:

class Foo { 
    use Config, Logger; 

    public function __construct() { 
     //want to use $this->config and $this->logger 
    } 
} 

To oczywiście nie działa, ponieważ bity konfiguracyjne są skutecznie duplikowane w Foo.

Mogę po prostu pominąć element use Config; z cechy Logger, wiedząc, że będzie tam na końcu. Ale wydaje mi się to dziwne, ponieważ tworzy rodzaj zewnętrznej zależności. Co się stanie, jeśli chcę użyć Logger w miejscu, które nie ma jeszcze cechy konfiguracyjnej? To rozwiązanie oznacza również, że muszę cierpieć z powodu mojego IDE (PhpStorm 8) ostrzegającego mnie przed nieznanymi metodami, a nie oferującego autouzupełniania. Zdaję sobie sprawę, że mogę rozwiązać te problemy po kolei, używając metody @method, ale to po prostu umieszczenie szminki na świni, że tak powiem.

Mogę również pseudo konfigurować bitów w Logger, ale to również problematyczne.

Wszystko to ma w sobie trochę zapachu, ale nie doszedłem jeszcze do tego, czy to dlatego, że jest to dla mnie nowy wzór, czy też naprawdę jest śmierdzący wzór. Tak czy siak, nie jestem pewien, jaki jest najlepszy sposób, aby to podejście faktycznie zadziałało.

Wszelkie porady dotyczące najlepszego sposobu rozwiązania tego problemu pod względem cech? A może lepiej unikać cech skracania DIC?

Answer 1

Metoda, którą uznałem za użyteczną, to używanie zarówno pobierających, jak i ustawiających. To pozwala ci wymagać, aby określony getter istniał, bez konfliktów z innymi cechami.

trait Config { 
    protected function SetConfig($config) { 
     $this->config = $config; 
    } 

    protected function GetConfig() { 
     return $this->config; 
    } 

    protected $config; 
} 

trait Logger { 
    abstract protected function GetConfig(); 

    protected function SetLogger($logger) { 
     $this->logger = $logger; 
    } 

    protected $logger; 
} 

class Baz { 
    use Config, Logger; 

    // ... 

} 

W Baz, cecha Config dostarcza wymaganej metody abstrakcyjnej, a Baz składa się bez błędów. Jeśli błędnie użyjesz tylko Logger, otrzymasz Błąd krytyczny: Bazę klasy zawiera 1 abstrakcyjną metodę i dlatego należy ją uznać za abstrakcyjną lub zaimplementować pozostałe metody (Baz :: GetConfig)