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


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

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.

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.

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

@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).

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 ?

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.

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.

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.

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

Powiedział co wiedział. Nawet się ortów nie będę czepiał

Bądź co bądź, to cojak ma rację w tym, że to nie jest Singleton.

LBO, ta klasa co zaprezentowałeś jest lekko zniekształconą implementacją wzorca Registry.

nospor niektórzy jednak tak uwarzają, podspodem link do skanu  z książki PHP i MySQL Vademecum Profesionalisty, odradzam ją wszystkim, którzy chcą się nauczyć php, wprowadza b.złe nawyki. Nie wiem co mogę polecić dla początkującego... ale wiem że ja zrobiłem źle, kupując tą książke (ale kiedy to bylo ).

Widać, że niektórzy nie wiedzą po co jest dziedziczenie. Ale oczywiście bo JAVA tak robi to już musi być dobre - rzygać zaczyna się chcieć od tego tworu.

W Javie interfacey również nie służą wielodziedziczeniu, służą one dokładnie temu czemu służą w PHP - wymuszeniu na danej klasie implementacji pewnych zachowań - metod.

Może i nie jest. Ale tylko dlatego, że ma sam wzorzec ma narzuconą implementację.
Poza tym wprowadzenie Singletona do aplikacji to nadal decyzja biznesowa. Są miejsca gdzie się sprawdzi, są takie gdzie już tego nie zrobi (jet to związane z tym, czy obiekt posiada stan, czy nie - kto ma zrozumieć to zrozumie).
Wyodrębnienie mechanizmu tworzącego Singletona ma tą zaletę, że:
1. Obiekty tworzy się jako bardziej reusable.
2. Większa kontrola nad kodem (dajmy na to języki z rozbudowaną wielowątkowością, dzięki mechanizmowi o którym pisaliśmy można decydować czy oba wątki mają dostać ten sam obiekt biznesowy, czy nie).
3. Z punktu drugiego można wnioskować, że testowalność obiektów się zwiększa.

Między innymi z powyższych powodów, uważa się Singletona (jako tego przedstawionego przez dajmy na to Wikipedię :D) za antywzorzec - a nie dlatego, że jest brzydki i niefajny.

Zawsze będę uważał, że Singletona da się zastąpić przemyślaną inżynierią

Dzięki temu forum dowiedziałem się o wzorcu Singleton przy łączeniu z jedną bazą danych i od tego czasu czasu go używam w tymże celu. Jeśli metody w np. dwóch klas wymagają nawiązania połączenia z bazą danych to bez singletona byłoby ciężko, tworzenie w takich klasach obiektów klasy odpowiadającej za połączenie z bazą danych byłoby bez sensu, bo gdybym następnie utworzył obiekty tych klas to byłyby dwa połączenia z bazą danych. Singleton ułatwia sprawę. W google jest o singletonie bardzo dożo informacji i z tego co wyczytałem należy do najważniejszych wzorców, nie wiem dlaczego go krytykujecie skoro on na prawdę jest pomocny.

Takie obiekty o jakich piszesz się przekazuje (dalej do innych instancji), a nie tworzy kilkakrotnie.

albo uzywa sie singletona, ktory zwraca instancje juz utworzonego obiektu. przeciez po to jest ten wzorzec

Singleton służy zapewnieniu, że w całej apliacji będzie tylko jeden obiekt danej klasy - po to jest ten wzorzec.

Czy ludzie nie czytają całych tematów? Patrzą tylko na dwa ostatnie posty i wyskakują z "genialnym" i "rozwiązującym wszelkie problemy (tj. głód, wojny i ubóstwo)" rozwiązaniem........ o_O?!?!?

sa ludzie, ktorzy zastanawiaja sie nad tym co pisza

Ale sa tez tacy co nie mysla nad tym co inni pisza

A jaka są właściwie zalety/wady używania w przypadku nawiązywania połączeń z bazą danych:

1. klasy do nawiązywania połączenia z bazą danych będącej singletonem; w drugiej klasie, której metody wymagają połączenia z bazą danych tworzenie w konstruktorze instancji klasy do nawiązywania połączenia z bazą danych przez wywołanie statycznej metody tej klasy zwracającej obiekt tej klasy

2. klasy do nawiązywania połączenia z bazą danych będącej zwykłą klasą; utworzenie obiektu tej klasy, utworzenie obiekt drugiej klasy, którego metody wymagają połączenia z bazą danych przekazując do jego konstruktora obiekt utworzonej uprzednio klasy do połączeń z bazą danych

?

Jest jakaś przewaga 1. sposobu nad 2. lub 2. nad 1. ?

Przewagi 2 na 1:
1) Możesz mieć wiele otwartych połączeń z bazą w tym samym czasie
2) Druga klasa staje się zdecydowanie bardziej elastyczna

Przewagi 1 nad 2:
-

Sorki ale nawet jakies opensource'owe cms'y/fora/portale korzystaja tylko z jednej bazy wiec to tylko jakis wynalazek chyba ze ktos pisze baze danych przestepcow dla FBI w USA to baz by musial miec 10

to ja może bez zbędnego pi****** dam link
http://codersview.blogspot.com/search/labe...sign%20patterns

NIe rozumiem po co ten link zeby poczytac na czym polegaja dane wzroce to ja wiem.

no to pojechali...
...ale chyba dobry temat znalazlem

szukalem jakiegos skryptu na ktorym moglbym sie powzorcowac, moze niekoniecznie arta bo jestem dupa z angielskiego
zaczalem czytac joomle, jest zdecydowanie za duza
moze ktos ma lepszy pomysl co by podejrzec jakies rozwiazania ?

joomle to poczytaj jak nie pisac. A na symfony sie ucz.

zaraz sciagne i zobacze, na pewno nie zaszkodzi, moze jeszcze zaczne pisac z frameworkiem
tylko symfony to framework, a ja bardziej chcialem zobaczyc jak sie buduje cmsy

zobacz sobie sympala to tzw. content management framework czyli framework do tworzenia cmsów oparty na symfony mający wiele zaawansowanych opcji przydatnych w budowaniu własnego backendu. fajnie się tez prezentuje apostrophe tez na bazie symfony umożliwiający kontekstową edycję strony na zasadzie edytowalnych bloków tekstu