🚀 go-pugleaf

On 2018-01-27, Marek S <precz@spamowi.com> wrote:

[...]

>> Różnica jest taka, że zależności dostarcza odpowiedni
>> manager, i kod który wykorzystuje te zależności nie ma
>> odpowiedzialności w której musi sobie daną zależność
>> sam "pobrać" - co jest najczęstszą wadą w projektach
>> opeartych o prosty singleton.
>
> Ok, to może inaczej - pójdźmy piętro wyżej. Czym jest zatem ten manager? 
> Czyż nie singletonem?

A jest powód by był singletonem?

> To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś 
> obiekt "guru".

Ale to jest powiedzmy kernel aplikacji, który postępuje wg pewnego ustalonego
sposobu. Gdzie tu widzisz potrzebę na singletona?

> Czy nazwiemy go tak czy siak, to i tak będzie sobie 
> istniał jako byt zainicjowany na początku, z którego istnienia czerpią 
> korzyści inni. Pojęcia leksykalne są czasem rozmyte.

Ja widzę różnicę:

<?php

class PobieramZBazy() {
    ___construct($cn) { $this->cn = $cn; }
    public getCostam() {
        return $this->cn->query(...);
    }
}

vs

class PobieramZBazy() {
    public getCostam() {
        $cn = JakisGlobalnyCusik::pobierzPolaczenie();
        return $cn->query(...);
    }
}

Tylko tyle i "aż" tyle, że to pierwsze się łatwiej testuje,
bo nie trzeba kombinować ze sztucznym mockowaniem statycznych
metod, tylko można sobie wstrzyknoć co potrzeba w kontrolerze.

Czyste i eleganckie. Oczywiście jak masz dobre zarządzanie
zależnościami, np. jak w Symfony2+.

A w 90% przypadków jakie widziałem, to Wielbiciele Singletonów
potrafili pisać masywną ilość metod statycznych, bo skoro "to
tak fajnie działa w przypadku singletona, to piszmy sobie 
skróty" :P

-- 
Wojciech Bańcer
wojciech.bancer@gmail.com