Wzorce projektowe, coto, poco, dlaczego Opcje

[pinochet]

Jeśli chodzi o serializację - można to oczywiście obejść ale jeśli chodzi o wygodę to może racja że lepiej singleton, aczkolwiek dalej twierdzę, że stosowanie wyżej wymienionych jest następstwem niechlujnego projektowania aplikacji. BTW po co serializować klasę łączącą z bazą danych?.
Co do php4 to się nie znam ... miałem przerwę między wersjami 3 i 5 :]
Chyba rzeczywiście z siebie głupka zrobiłem ...

[wrzasq]

dalej twierdzę, że stosowanie wyżej wymienionych jest następstwem niechlujnego projektowania aplikacji

bo zes sobie ubzdural, ze singleton to jakies "obejscie z PHP4" albo tylko i wylacznie "zamiennik dla rejestru/kontekstu/klasy statycznej". na tym polega istota singletonu wlasnie, ze udostepnia on instancje (obiekt) danej klasy i pozawala na istnienie TLYKO JEDNEJ takiej instancji. nie chodzi o przekazywanie go w jakis niejawny sposob, tylko o zapobieganie tworzenia wiecej niz jeden instancji klasy, ktora nie powinna miec ich tyle. to jest istota singletonu.

[LBO]

Dorzucę swoje 0,02zl

Singleton nie jest złym wzorcem. Ma swój sens i cel. Niestety implementacje, które są propagowane w światku PHP (ten z getInstance()) kuleją bardzo z powodu niewrażliwości na kontekst wywołania i zafałszowania (narzuca obiektowi działanie niezgodne z jego dziedziną). Robią się z Tego takie globale. Wspomniał ktoś tutaj, że hermetyzacje (każdej aplikacji) można złamać na wiele sposobów. Trudno się z tym nie zgodzić, ale czy to powód, że od samego początku, że się tak wyrażę kolokwialnie, srać sobie w kodzie?

Bardzo ładnie radzą sobie frameworki, chociażby, Javowe używając prześwietnych kontenerów IoC. To one załatwiają sprawę singletona, więc pisząc obiekt nie zastanawiasz się, czy ma być singletonem (separation of concerns), czy nie. I nie natkniesz się na problem przy testowaniu takiego obiektu Bo testability leci pod sufit wtedy.

Ten post edytował LBO 19.04.2009, 10:14:38

[nasty]

Dlaczego singleton nie jest antywzorcem? Przykladem jest sesja. moze byc tylko jedna. Nie mozemy wiec pozwolic na tworzenie wiecej niz jednego obiektu sesji, bo to mogloby miec fatalne skutki, np zniszczeniem danych sesyjnych. No i oglnie rzecz biorac, Sesja jest jedna, wiec jak moze byc reprezentowana przez kilka obiektow?

Pozwolę sobie nie zgodzić się i wyprowadzić Cie z błędu przy okazji

Załóżmy, że klasa Session jest klasą która opisuję sesję. Tworzona jest tylko raz, na początku działania frameworku, następnie przekazywana do Request, następnie, Controller i potem do Response.

Jak widać masz jedną klasę, która ma swoje określone workflow, wiadomo w jakiej kolejności co i jak ma do niej dostęp - w taki sposób, że możesz narysować diagram "podań" ten klasy. Czy taki model nie jest dużo czytelniejszy niż singleton?

I teraz rozważmy możliwość tworzenia nowych instancji Sessji, gdzie wiemy, że sesja jest tylko jedna.

Jak to bywa z obiekatmi kontekstowymi, są one przekazywane w parametrach metod do kolejnych klas, i nawet jak utworzysz nowy obiekt klasy Session, to on i tak będzie pusty a spopulowany danymi obiekt będzie tylko ten który był w parametrze - więc jaki problem? imho, żaden.

Za używanie Singletonów powinni bić po mordzie i tyle

[nasty]

@nasty
tak wlasnie programuja w microsofcie (...)

Potraktuję to jako komplement

[qba_rox]

@nasty
Pozwole sobie odpisac

Smiem poddac w watpliwosc twoje zrozumienie singletonu. Singleton nie definuje ci jak ma przebiegac workflow obiektu. Chodzi tu o nic innego, jak tylko o mozliwosc powolania jednej instrancji. Sesja jest z definicji bytem takim jak np u czlowieka swiadomosc. Mozesz miec tylko jedna i nie mozesz miec drugiej chocby byla pusta
Wiec nie mozesz nawet pozwolic na utworzenie obiektu, bo jest to poprostu nie zgodne z logika. Sa pewne byty, ktore nie moga byc traktowane jak np myszka od komputera, ktorej "objekt" w fabryce myszek jest "tworzony" wielokrotnie

A wracajac do twojego workflow, to co stoi na przeszkodzie dac dostep do metody 'getInstance()' tylko raz? Mam na mysli, ze jesli obiekt jest juz powolany, to getInstance zeby zwracala null i nikt nie bedzie wtedy traktowal jej jako global i zachowasz swoj magiczny workflow, ktory prawdopodobnie jest spoko i ma duzo sensu w sobie

btw. nie jestem fanem traktowania singletonu jako ominiecia zmiennych globalnych

[nasty]

Drogi @qba_rox, zauważ jednak, że takie uniemożliwianie wykonania getInstance() więcej niż jeden raz, jest już takjakby hackiem singletona, a to samo masz w obiekcie kontekstowym, on jest przekazywany tylko raz.

Załóżmy taką sytułację, że w pewnym momencie chciałbyś odtworzyć pewną sesję - np. masz aplikację z opcją "zapisz sesję" i po ponownym uruchomieniu, chciałbyś, żeby wszystko było jak po zamknięciu. Singleton Ci na to nie pozwoli, gdyż możesz tylko uzyskać obiekt który jest tworzony w ukrytym konstruktorze, nie możesz odtworzyć stan zachowanego (załóżmy, że zserializowanego) obiektu do tej ukrytej instancji, zachowanej w Singletonie. A z obiektem kontekstowym można takie coś zrobić.

A odnośnie świadomości... wydaję mi się, że za bardzo puściłeś wodzę fantazji przyrównując ją do sesji, bo jak wspomniałem, sesję można zachować, nie używać jej a następnie odtworzyć a świadomość nie, no chyba, że mówimy tu o bardzo zakrapianej alkoholem imprezie

[qba_rox]

Drogi @qba_rox, zauważ jednak, że takie uniemożliwianie wykonania getInstance() więcej niż jeden raz, jest już takjakby hackiem singletona, a to samo masz w obiekcie kontekstowym, on jest przekazywany tylko raz.

Nie, nie jest hackiem. nadal pozwala ci powolac obiekt tylko raz, a to jest definicja singletona.

Załóżmy taką sytułację, że w pewnym momencie chciałbyś odtworzyć pewną sesję - np. masz aplikację z opcją "zapisz sesję" i po ponownym uruchomieniu, chciałbyś, żeby wszystko było jak po zamknięciu. Singleton Ci na to nie pozwoli, gdyż możesz tylko uzyskać obiekt który jest tworzony w ukrytym konstruktorze, nie możesz odtworzyć stan zachowanego (załóżmy, że zserializowanego) obiektu do tej ukrytej instancji, zachowanej w Singletonie. A z obiektem kontekstowym można takie coś zrobić.

Jesli chcesz zastosowac swoj workflow, to oboje wiemy ze nie ma problemu, natomiast jesli chcemy miec dostep do sesji z kazdego miejsca aplikacji, to wtedy masz racje. jest to problem, ale do obejscia. wystorczy dodac metody, extract i populate

A odnośnie świadomości... wydaję mi się, że za bardzo puściłeś wodzę fantazji przyrównując ją do sesji, bo jak wspomniałem, sesję można zachować, nie używać jej a następnie odtworzyć a świadomość nie, no chyba, że mówimy tu o bardzo zakrapianej alkoholem imprezie

Hehhehe, dobre. Chocidzlo mi tu bardziej o byt

[Cysiaczek]

@nasty - a co jeśli obiekt, który tworzymy, dokonuje przy własnej konstrukcji zadania wpływające na resztę systemu, czy choćby dane?

[PHP] pobierz, plaintext 
<?php
class Ping
{
    public function __construct(VeryImportantLogger $oLogger)
    {
        $oLogger->log(__CLASS__);
    }
}
 
class LogAnalyzer
{
    public function pong(VeryImportantLogger $oLogger)
    {
        if(oLogger->hasMany('Ping'))
        {
            $this->callAlert();
            die();
            exit();
            burnDisk('C:'); // 
        }
    }
}
?>
[PHP] pobierz, plaintext 

[nasty]

@Cysiaczek, robi to samo, tyle, że na początku swojej podróży (workflow).

A nawet nie koniecznie na początku, może nawet w środku. Z tym, że mając to ładnie ułożone w workflow, wiemy dokładnie w której fazie aplikacji wszystko się dokonuję (w singletonie też niby wiemy, ale nie mamy takiej kontroli nad tym).

... i Cysiaczek, mógłbyś trochę bardziej rozjaśnić swoją myśl? bo wydaję mi się, że czytając ten kod mam lekki ocb

[Cysiaczek]

To jest ilustracja do pytania, które zadaję Tobie w nawiązaniu do:

Jak to bywa z obiekatmi kontekstowymi, są one przekazywane w parametrach metod do kolejnych klas, i nawet jak utworzysz nowy obiekt klasy Session, to on i tak będzie pusty a spopulowany danymi obiekt będzie tylko ten który był w parametrze - więc jaki problem? imho, żaden.

Utworzenie wielu instancji klasy Ping w tym konkretnym przypadku skutkuje katastrofą w zupełnie nieoczekiwanym miejscu. Aby temu zapobiec, należy uniemożliwić powołanie więcej niż jednej instancji klasy Ping, a więc skorzystać z wzorca Singleton. To jest przypadek uzasadnionego użycia.

Pozdrawiam

[LBO]

...

Cysiaczku, jak mniemam nie spotkałeś się jeszcze z kontenerami IoC? Są one najlepszym przykładem, że logika odpowiedzialna za powoływanie singletonów powinna być zewnętrzna. Kod jest prostszy, a nasty wskazał dobry przykład gdzie getInstance tylko komplikuje wszystko.

[pejott]

Cały problem w tym, że zaczęto implementować wzorzec singleton w celu udostępnienia jakiegoś obiektu w całej aplikacji.
Ma on swoje konkretne i teoretycznie jedno przeznaczenie, czyli uniemożliwienie stworzenia kilku instancji obiektu.
Wiele osób stosuje go, na przykład przy obiekcie do zarządzania bazą danych, co jest dla mnie bzdurnym rozwiązaniem.
Jest to wręcz nielogiczne, gdyż czasem potrzebujemy wielu połączeń z różnymi bazami.
Ja odciąłem się od singletona w moich projektach i jakoś żyję.

Pozdrawiam.

[nospor]

Ja odciąłem się od singletona w moich projektach i jakoś żyję.

Mozna sie odciac od obiektowki i pisac tylko strukturalnie i też mozna jakos zyc

Wszystko zalezy od własciwego wykorzystania i umiejetnosci programisty. Toczy sie równolegle temat o dziedziczeniu i tam dochodzą do podobnych wniosków

[LBO]

Cały problem w tym, że zaczęto implementować wzorzec singleton w celu udostępnienia jakiegoś obiektu w całej aplikacji.
Ma on swoje konkretne i teoretycznie jedno przeznaczenie, czyli uniemożliwienie stworzenia kilku instancji obiektu.
Wiele osób stosuje go, na przykład przy obiekcie do zarządzania bazą danych, co jest dla mnie bzdurnym rozwiązaniem.
Jest to wręcz nielogiczne, gdyż czasem potrzebujemy wielu połączeń z różnymi bazami.
Ja odciąłem się od singletona w moich projektach i jakoś żyję.

Pozdrawiam.

@pejott, umknęło Tobie chyba, że tu nikt nie neguje singletona jako zbędnego wzorca.
To jest raczej wojna o to jak dochodzić do singletona. Jawnie - zaszywając logikę wewnątrz obiektu (np. getInstance()) czy niejawnie - czyli tworzenie obiektow gdzieś w niższej warstwie aplikacji i kontrolowane i ścisłe udostępnianie ich wyżej (loadery, kontenery i kontekst).

Ten post edytował LBO 13.05.2009, 11:46:50

[pejott]

No tak, to było tylko ogólne spostrzeżenie na temat całego zamieszania wokół tego wzorca.
Teraz każdy początkujący w OOP, który usłyszał negatywną opinię na temat implementacji wzorca, nieświadomie twierdzi, że singleton jest zły.
Co do tej właściwej kwestii, to skłaniałbym się ku temu drugiemu rozwiązaniu, choć nie jestem pewien jak miałoby to wyglądać ?
Sam nie stosuje tego wzorca, ale wydaję mi się, że mam podobnie rozwiązaną kwestie przekazywania i kontrolowania dostępu do obiektów.
Mógłbyś podać przykład jak taki obiekt miałby być "powoływany do życia" i przekazywany dalej ?

Ten post edytował pejott 13.05.2009, 18:02:45

[LBO]

Przygotowałem malutki przykładzik. Mam nadzieję, że pomoże.

[PHP] pobierz, plaintext 
<?php
class Container
{
    /**
     * Tablica singletonów.
     * 
     * @var array
     */
    public $singletons = array();
 
    /*
     * Tutaj sprawdzam czy kontener ma zwrócić singleton na podstawie jawnego
     * interfejsu.
     * W prawdziwej pełnej implementacji kontener może to robić na podstawie
     * konfigu (np. XML) i/lub adnotacji phpDoc (np. @singleton).
     */
    public function get($classname)
    {
        $reflection = new ReflectionClass($classname);
        if($reflection->implementsInterface('Singleton'))
        {
            if(!array_key_exists($classname, $this->singletons)) {
                $this->singletons[$classname] = new $classname;;
            }
            return $this->singletons[$classname];
        } else {
            return new $classname;
        }
    }
}
 
interface Singleton
{}
 
/*
 * To będzie singleton
 */
class User implements Singleton
{}
 
/*
 * A to nie będzie singletonem :)
 */
class Article
{}
 
$container = new Container();
$user1 = $container->get('User');
$user2 = $container->get('User');
var_dump($user1 === $user2); // true
 
$article1 = $container->get('Article');
$article2 = $container->get('Article');
var_dump($article1 === $article2); // false
 
?>
[PHP] pobierz, plaintext 

edit:

Oczywiście podany przykład jest bardzo abstrakcyjny (w programistycznym sensie słowa). Np we frameworku Agavi ten sposób stosowany jest tylko przy pobieraniu klas modeli (agaviContext::getModel()) reszta obiektów jest za to wstrzykiwana do obiektu kontekstu.

Ten post edytował LBO 13.05.2009, 13:03:23

[pejott]

Dzięki, właśnie tak to sobie wyobrażałem i prawie identycznie mam to rozwiązane u siebie, lecz w trochę innym kontekście/celu.

Pozdrawiam.

[cojack]

Taki mi to singleton ze hoho, po prostu zwykly chory polimorfizm. To tak ja cala hora zabawa z interfejsami. A jak mi ktoś napisze że interfejsy rozwiązują wielodziedziczenie to własnymi rękoma udusze.

[nospor]

A jak mi ktoś napisze że interfejsy rozwiązują wielodziedziczenie to własnymi rękoma udusze

To teraz leć na forum motoryzacyjne i wal z postem

A jak mi ktoś napisze że samochody rozwiązują problem latania to własnymi rękoma udusze

Oczywiste jest, ze interfejsy nie do tego sluzą, tak jak nie sluzą samochody do latania. Nie ma sensu wiec uprzedzac wypowiedzi wiedzących inaczej i walic takie posty