Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #15646 > unrolled thread

Dobre praktyki

Back to article view | Back to pl.comp.lang.php

Contents

  Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-18 13:37 +0100
    Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-18 18:30 +0100
      Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:31 +0100
        Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-25 20:44 +0100
          Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:48 +0100
            Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-25 21:22 +0100
              Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 23:55 +0100
                Re: Dobre praktyki Lemat <#@lemat.priv.pl> - 2018-01-26 05:48 +0100
                  Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 13:48 +0100
              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:02 +0100
                Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-26 23:16 +0100
                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:09 +0100
                    Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:04 +0100
                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:07 +0100
                        Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:22 +0100
                        Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:31 +0100
            Re: Dobre praktyki artiun <artiun@spam.wp.pl> - 2018-01-26 00:06 +0100
    Re: Dobre praktyki denat 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2018-01-18 20:03 +0100
    Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-21 05:03 -0800
      Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-21 22:38 +0100
      Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-22 21:56 +0100
        Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 08:16 -0800
          Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-24 17:20 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:30 -0800
              Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:46 +0100
              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-25 21:10 +0100
                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 00:03 +0100
                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-26 00:26 +0100
                    Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-26 14:00 +0100
                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 13:05 +0100
                        Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 13:40 +0100
                          Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 14:49 +0100
                            Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 19:04 +0100
                              Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 20:35 +0100
                                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 21:59 +0100
                                  Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-27 23:02 +0100
                                    Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:35 +0100
                                      Re: Dobre praktyki Wojciech Bancer <wojciech.bancer@gmail.com> - 2018-01-28 00:24 +0100
                          Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:49 +0100
                            Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:08 +0100
                              Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 23:26 +0100
                                Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-27 23:56 +0100
                                  Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-28 00:34 +0100
          Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-24 20:29 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-24 21:51 -0800
            Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:43 +0100
              Re: Dobre praktyki Roman Tyczka <noemail@because.no> - 2018-01-29 08:48 +0100
                Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-30 20:37 +0100
          Re: Dobre praktyki Borys Pogoreło <borys@pl.edu.leszno> - 2018-01-27 22:45 +0100
            Re: Dobre praktyki Rafal Podsiadly <spinacz24@gmail.com> - 2018-01-28 07:08 -0800
      Re: Dobre praktyki Marek S <precz@spamowi.com> - 2018-01-25 20:36 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#15661

Dnia Sun, 21 Jan 2018 05:03:14 -0800 (PST), Rafal Podsiadly napisał(a):

> 3. Wykorzystuj zmienne statyczne w stałych plikach (ograniczysz kopiowanie zmiennych).

Możesz rozwinąć?

> 4. Poznaj różnicę między przekazaniem argumentu do funkcji a argumentu do metody (klasa w funkcji) 

Jw. W internals są jakieś konkretne różnice, które trzeba mieć na uwadze?

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15663

Zmienne statyczne singelton cos ci mowi?

Poczytaj tez o przekazywaniu zmiennej do metody w klasie a przekazywaniu zmiennej do funkcji. O klasach statycznych. Różnicach w wykorzystaniu or and w warunku if. W jaki sposob robic dobre warunki. Czyli mapa wynikow zanim zaczniemy pisac zlozony if.

O tym ze lepiej na poczatku funkcij sprawdzic warunek konieczny 5 linijek i zrzucic blad niz opakowac 100 linijek kogu w if. O tym jak dzialaja if a funkcie. I czy warto.

[toc] | [prev] | [next] | [standalone]

#15664

On 2018-01-24, Rafal Podsiadly <spinacz24@gmail.com> wrote:
> Zmienne statyczne singelton cos ci mowi?

Singleton został uznany za anti-pattern gdzieś w okolicach
popularyzacji dependency-injection pattern.

Z wielu powodów.

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

[toc] | [prev] | [next] | [standalone]

#15666

To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

[toc] | [prev] | [next] | [standalone]

#15672

W dniu 25-01-2018 o 06:30, Rafal Podsiadly pisze:

> To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

Właśnie to samo chciałem od siebie napisać.
Dodam jedynie, że w swoich projektach nieco to obszedłem (może to złe 
wyrażenie - opakowałem ładniej) tworząc klasę narzędziową nadrzędną do 
wszystkich pozostałych. W niej m.in. nawiązuję połączenie z bazą i 
monitoruję poprawność zamykania handlerów przez wszystkie pozostałe 
klasy itp.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15674

On 2018-01-25, Rafal Podsiadly <spinacz24@gmail.com> wrote:

> To prawda singeltona trzeba umiec uzywac. Np. W bazach danych do utrzymywania polaczen.

https://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern
https://www.michaelsafyan.com/tech/design/patterns/singleton

Bazy danych to najczęściej factory.
A singletony to pain-in-the-ass podczas pisania testów.

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

[toc] | [prev] | [next] | [standalone]

#15679

W dniu 25-01-2018 o 21:10, Wojciech Bancer pisze:

> https://stackoverflow.com/questions/12755539/why-is-singleton-considered-an-anti-pattern
> https://www.michaelsafyan.com/tech/design/patterns/singleton
> 
> Bazy danych to najczęściej factory.
> A singletony to pain-in-the-ass podczas pisania testów.
> 

Cytat z linku jaki przesłałeś zachęca do singletonów przy bazach :-)

If you find that you want to use a singleton, you may want to consider 
your design, but there are times where it is useful.

For example, once I had to write an application that could have at most 
one database connection, to process thousands of requests. So, a 
singleton makes sense since I am resource constrained to having only one 
instance.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15683

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

[...]

> For example, once I had to write an application that could have at most 
> one database connection, to process thousands of requests. So, a 
> singleton makes sense since I am resource constrained to having only one 
> instance.

To doczytaj komentarze do tego :)


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

[toc] | [prev] | [next] | [standalone]

#15686

W dniu 26-01-2018 o 00:26, Wojciech Bancer pisze:

> 
> To doczytaj komentarze do tego :)

Oj pewnie! :-) A Ty doczytaj kolejne :-D

W ten sposób cały dzień gadać można: ktoś będzie ciągnął w jedną stronę, 
ktoś inny w drugą. Tymczasem temat jest prosty w/g mnie. Wielokrotne 
inicjowanie połączenia do bazy danych jest katastrofą dla wydajności 
softu. Zrobienie tego raz na początku i posprzątanie na końcu jest 
jedyną słuszną (moim prywatnym zdaniem) drogą. Aby "coś" móc zrobić z 
danym obiektem na początku i na końcu to musi on cały czas istnieć 
miedzy początkiem a końcem. Prawda? Wtedy zbliżamy się do singletonów 
lub pokrewnych rozwiązań.

Zwróć uwagę, że pojęcie sesji w PHP/ASP/czymkolwiek też jest takim 
niby-singletonem a jakoś nikt nie rozpacza nad jej istnieniem.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15689

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

[...]

>> To doczytaj komentarze do tego :)
>
> Oj pewnie! :-) A Ty doczytaj kolejne :-D
>
> W ten sposób cały dzień gadać można: ktoś będzie ciągnął w jedną stronę, 
> ktoś inny w drugą. Tymczasem temat jest prosty w/g mnie. Wielokrotne 
> inicjowanie połączenia do bazy danych jest katastrofą dla wydajności 
> softu.

Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
Doczytaj sobie o wzorcach dependency injection.

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

[toc] | [prev] | [next] | [standalone]

#15692

W dniu 27-01-2018 o 13:05, Wojciech Bancer pisze:

> 
> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
> Doczytaj sobie o wzorcach dependency injection.

Ale to właśnie jest jedną z implementacji takich singletonów - tu 
zwanych pluginami. Różnica leksykalna.

Cytat z Wiki:
"Polega na przekazywaniu gotowych, utworzonych instancji obiektów 
udostępniających swoje metody i właściwości obiektom, które z nich 
korzystają (np. jako parametry konstruktora)"

Te "gotowe instancje" to są nic innego jako singletony wygenerowane 
przez ich fabrykę. Przez fabrykę otrzymujesz globalny dostęp do 
stworzonych obiektów - a taka jest właśnie definicja singletonów.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15693

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


>> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
>> Doczytaj sobie o wzorcach dependency injection.
>
> Ale to właśnie jest jedną z implementacji takich singletonów - tu 
> zwanych pluginami. Różnica leksykalna.

Nie, różnica nie jest leksykalna.

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.

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

[toc] | [prev] | [next] | [standalone]

#15694

W dniu 27-01-2018 o 14:49, Wojciech Bancer pisze:

> 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?

To co chcę powiedzieć, to to, że zawsze na szczycie aplikacji jest jakiś 
obiekt "guru". 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.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15695

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

[toc] | [prev] | [next] | [standalone]

#15696

W dniu 27-01-2018 o 20:35, Wojciech Bancer pisze:

> 
> A jest powód by był singletonem?

Poniżej

> 
>> 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?

Właśnie, trafiłeś w sedno w sformułowaniu "ale to jest _powiedzmy_ 
kernel". Słowo klucz to "powiedzmy". Mógłbym powiedzieć "zgoda" albo 
mógłbym powiedzieć "to jest właśnie singleton" i na jedno by wyszło. 
Kernel jest singletonem.

Zobrazuję to na podstawie Twojego przykładu. Oczywiście należy tak 
postępować jak poniżej:

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

...ale właśnie teraz wpadasz w pułapkę tego, o czym cały czas piszę. 
Skąd masz połączenie do bazy $cn? Gdzieś ono musiało być zainicjowane i 
przechowywane przez całą długość życia aplikacji. Prawda? Zrobi to nasz 
"kernel" i udostępni innym obiektom handler do raz ustanowionego połączenia.

Teraz popatrz jak powstaje z kernela singleton:

class kernelZwanySingletonem() {
	private $connection;
	
	public function getConnection() {
		return $connection;
	}
	
	__construct() {
		//tu kupa kodu plus inicjacja bazy
		$this->$connection=...
	  }

	__destruct() {
		//tu kupa kodu
		zamknijPołączenieZBazaIZapiszLogi($connection);
	}
}

$singleton=new kernelZwanySingletonem();
$singleton->runApplication();

...aplikacja sobie działa i potrzebuje w pewnym momencie dostępu do 
bazy. I co wtedy robi? A no to co napisałeś.

$cosTam=new PobieramZBazy($singleton->getConnection());
$wyniki=$cosTam->getCosTam();

... aplikacja dalej pracuje i znów jakiś inny jej moduł potrzebuje 
grzebania w bazie więc:

$cosTam2=new PobieramZBazyCosInnego($singleton->getConnection());
$wyniki=$cosTam2->getCosTam();

Gdy aplikacja kończy żywot, to niejawnie wołany jest destruktor kernela 
zwanego singletonem. Baza pięknie się zamyka, ba, można nawet sprawdzić 
w tym miejscu czy moduły pozamykały prawidłowo swoje recordsety i jeśli 
nie, to w logach zapisać alerty.

Ten nasz "kernel" czy klasa "guru" to właśnie nasz singleton. Z jego 
egzystencji wszelkie pozostałe funkcjonalności czerpią soki.

I jeszcze jedno: singleton to nie jest masywna ilość statycznych metod. 
Singleton nie musi mieć żadnej statycznej. Cytat z Wiki:

"Singleton – kreacyjny wzorzec projektowy, którego celem jest 
ograniczenie możliwości tworzenia obiektów danej klasy do jednej 
instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu."

Nasz kernel wypełnia wszelkie przesłanki bycia singletonem i jest on 
jedynym singletonem w całej aplikacji tej mini aplikacji. Nawet ciężko 
mi sobie wyobrazić aplikację, nie ma żadnego nadrzędnego obiektu, który 
siłą rzeczy staje się singletonem. No chyba, że programujemy liniowo w 
jakimś Basicu itp. Ważne jest aby tylko jeden tego typu obiekt 
występował pełniąc rolę np. managera pluginów (z pluginem bazy danych 
włącznie) - jak to wcześniej nazwaliśmy.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15701

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

[...]

>>> 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?
>
> Właśnie, trafiłeś w sedno w sformułowaniu "ale to jest _powiedzmy_ 
> kernel". Słowo klucz to "powiedzmy". Mógłbym powiedzieć "zgoda" albo 
> mógłbym powiedzieć "to jest właśnie singleton" i na jedno by wyszło. 
> Kernel jest singletonem.

A skąd założenie że jest singletonem?

> ...ale właśnie teraz wpadasz w pułapkę tego, o czym cały czas piszę. 
> Skąd masz połączenie do bazy $cn? Gdzieś ono musiało być zainicjowane i 
> przechowywane przez całą długość życia aplikacji. Prawda? Zrobi to nasz 
> "kernel" i udostępni innym obiektom handler do raz ustanowionego połączenia.

I ponownie, skąd założenie że jest singletonem?

> Teraz popatrz jak powstaje z kernela singleton:
>
> class kernelZwanySingletonem() {
> 	private $connection;
> 	
> 	public function getConnection() {
> 		return $connection;
> 	}
> 	
> 	__construct() {
> 		//tu kupa kodu plus inicjacja bazy
> 		$this->$connection=...
> 	  }
>
> 	__destruct() {
> 		//tu kupa kodu
> 		zamknijPołączenieZBazaIZapiszLogi($connection);
> 	}
> }
>
> $singleton=new kernelZwanySingletonem();
> $singleton->runApplication();

Gdzie tu widzisz wzorzec singletona?
Rozumiesz czym jest ten wzorzec?

> ...aplikacja sobie działa i potrzebuje w pewnym momencie dostępu do 
> bazy. I co wtedy robi? A no to co napisałeś.

Nie. Aplikacja w konfiguracji trzyma opisy zależności dla poszczególnych
serwisów i udostępnia konterner z tymi serwisami, już zainicjalizowanymi
(lub inicjowanymi w momencie pierwszego załadowania jak dana zależność
wspiera lazy loading). Jednak w tym momencie nie potrzebujemy w ogóle
zmiennych statycznych, a ponieważ inicjalizuje i kontroluje wszystko 
manager, to mamy kontrolę nad ilością tworzonych obiektów bez uciekania
się do sztuczek z wzorcem singletona.

> I jeszcze jedno: singleton to nie jest masywna ilość statycznych metod. 
> Singleton nie musi mieć żadnej statycznej. Cytat z Wiki:
>
> "Singleton – kreacyjny wzorzec projektowy, którego celem jest 
> ograniczenie możliwości tworzenia obiektów danej klasy do jednej 
> instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu."

Nie.
1. Nie ma potrzeby zapewniania globalnego dostępu
2. Możesz tworzyć więcej obiektów, po prostu nie jest to potrzebne.

Wzorzec singletona zakłąda w praktyce istnienie konstruktora
prywatnego i metody statycznej go jego tworzenia. Wtedy jesteś
w stanie zapewnić oba powyższe punkty.

> Nasz kernel wypełnia wszelkie przesłanki bycia singletonem i jest on 
> jedynym singletonem w całej aplikacji tej mini aplikacji.

Nie wypełnia.

> Nawet ciężko mi sobie wyobrazić aplikację, nie ma żadnego nadrzędnego 
> obiektu, który siłą rzeczy staje się singletonem.

No to mamy niezgodę, bo ja nie uznaję dowolnego pojedynczego obiektu
za singletona tylko dlatego że jest jeden :P

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

[toc] | [prev] | [next] | [standalone]

#15708

W dniu 27-01-2018 o 23:02, Wojciech Bancer pisze:

> A skąd założenie że jest singletonem?

To nie założenie. Bo (raczej) nie może być czymkolwiek innym.


> Gdzie tu widzisz wzorzec singletona?

W tym, że jest obiekt nadrzędny nad wszystkimi, który tylko można 
zainicjować i nic więcej. W całej aplikacji zawiera tylko jedno 
zainicjowanie. Jest singlem.

> Rozumiesz czym jest ten wzorzec?

Być może. Sprostuj mnie jeśli błędnie to ujmuję.

> No to mamy niezgodę, bo ja nie uznaję dowolnego pojedynczego obiektu
> za singletona tylko dlatego że jest jeden :P

No więc jesteśmy coraz bliżej zdefiniowania rozbieżności interpretacji. 
:-) Nie bardzo rozumiem czemu przyjmujesz definicję z Wiki za 
nieprawdziwą. Może małymi krokami i na przykładzie.

Ok, powiedz mi na podstawie kodu:

class cosTam() {}
$obj=new cosTam();

Powyższe to całość aplikacji. Nie ma więcej kodu. To jest jedna klasa i 
obiekt z niej. Czy jest to wzorzec singletona czy DI czy cokolwiek? Bo 
dla mnie to czysty singleton zgodny z definicją Wiki. Załóżmy, że 
odpowiesz mi cokolwiek. Teraz dostawiamy jedną metodę do tej klasy. Czy 
coś się zmienia w tym co mi odpowiedziałeś? Pewnie nie. No to lećmy 
dalej: budujemy inne klasy, które zaczynają korzystać z powyższej bo 
powyższa np. udostępnia połączenie do bazy a inne go pragną. Od jakiego 
momentu powyższa klasa przestaje być singletonem a zaczyna być DI?

Wyjaśnię jak ja rozumuję. Jedyna klasa w całej aplikacji musi być 
singletonem. Nawet jeśli dostawi się do niej mnóstwo właściwości i metod 
to nic się nie zmieni. Jeśli dostawimy teraz inne klasy, które 
komunikują się z powyższą, to mogą one zacząć stanowić model DI. Wtedy 
mówimy, że wszystkie pozostałe klasy "pracują" w/g wzorca DI. Jednakże 
nie pozwala to przechrzcić klasy nadrzędnej. Ona udostępnia interfejs DI 
ale sama jest singletonem.

Twój ruch :-)

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#15710

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

[...]

>> Gdzie tu widzisz wzorzec singletona?
>
> W tym, że jest obiekt nadrzędny nad wszystkimi, który tylko można 
> zainicjować i nic więcej. W całej aplikacji zawiera tylko jedno 
> zainicjowanie. Jest singlem.

To nie jest definicja wzorca singletona.

[...]

>> za singletona tylko dlatego że jest jeden :P
>
> No więc jesteśmy coraz bliżej zdefiniowania rozbieżności interpretacji. 
>:-) Nie bardzo rozumiem czemu przyjmujesz definicję z Wiki za 
> nieprawdziwą. Może małymi krokami i na przykładzie.
>
> Ok, powiedz mi na podstawie kodu:
>
> class cosTam() {}
> $obj=new cosTam();
>
> Powyższe to całość aplikacji. Nie ma więcej kodu. To jest jedna klasa i 
> obiekt z niej. Czy jest to wzorzec singletona czy DI czy cokolwiek?

Nie. Singleton ma prywatny konstruktor i nie pozwala na stworzenie obiektu
poza kontrolą tegoż singletona. W innym wypadku:
1) nie jesteś w stanie zagwarantować globalności obiektu
2) nie jesteś w stanie zagwarantować, że obiekt jest stworzony raz.

Singleton to coś w stylu:

class cosTam() {
  private static $instance = null;
  private function __construct() {}
  public static function getInstance() {
    if (self::$instance == null) {
      self::$instance = new Singleton();
    }

    return self::$instance;
  }
}

W Java masz podobnie:
https://en.wikipedia.org/wiki/Singleton_pattern#Implementation

Każdy singleton zakłada kontrolę nad tworzeniem instancji takiego
obiektu. Jeśli jej nie ma, to nie jest to singleton.

To że sobie zrobisz klasę i użyjesz raz nie czyni z niej singletona.

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

[toc] | [prev] | [next] | [standalone]

#15699

Dnia Sat, 27 Jan 2018 13:40:24 +0100, Marek S napisał(a):

>> Nikt nie pisał o wielokrotnym inicjowaniu połączeń.
>> Doczytaj sobie o wzorcach dependency injection.
> 
> Ale to właśnie jest jedną z implementacji takich singletonów - tu 
> zwanych pluginami. Różnica leksykalna.

Nie. DI to kontrolowane przekazywanie obiektu, zamiast magicznego
pojawiania się tego obiektu gdzieś wewnątrz kodu.

Wojtek próbuje Ci wytłumaczyć, że to ma krytyczne znaczenie podczas testów,
gdzie często nie masz dostępu do połączenia z bazą. Albo z takiego
połączenia byłoby więcej problemów, niż pożytku.

Owszem, jeden singleton jeszcze da się jakoś obejść. Ale ten wzorzec często
kusi.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#15704

W dniu 27-01-2018 o 22:49, Borys Pogoreło pisze:

> Wojtek próbuje Ci wytłumaczyć, że to ma krytyczne znaczenie podczas
> testów, gdzie często nie masz dostępu do połączenia z bazą. Albo z
> takiego połączenia byłoby więcej problemów, niż pożytku.
> 
> Owszem, jeden singleton jeszcze da się jakoś obejść. Ale ten wzorzec
> często kusi.

Ja to wszystko doskonale rozumiem. Chodzi mi o zupełnie coś innego.
Przeczytaj moją ostatnią wypowiedź udzieloną Wojtkowi. Wyjaśnię o jaki 
tok rozumowania mi chodzi. Za pomocą singletonów niektórzy piszą całą 
aplikację. Tego nawet nie biorę pod uwagę.

Chodzi mi o to, że nie da się w zasadzie tak napisać aplikacji aby nie 
miała jednego, nadrzędnego singletona. Cała aplikacja bazuje na modelu 
DI ale jej "kernel" _zawsze_ musi być zainicjowany globalnie. A jeśli 
jest zainicjowany globalnie to staje się singletonem.

Pojęcie singletona dotyczy tylko nadrzędnego obiektu dla wszystkich. 
Cała reszta może nie spełniać definicji singletonów.

Może to abstrakcyjnie zilustruję. Niech oprogramowanie DI przypomina 
książkę. Są w niej rozdziały, w rozdziałach zdania, w zdaniach wyrazy. 
Widać hierarchię. Każdy z wyrazów, rozdziałów ma dostęp do książki, 
której część stanowi. Książka pozwala na współzależność rozdziałów.

A od czego zależy sama książka? Od niczego! Stanowi samoistny byt. 
Singleton! :-) Uruchamiamy na serwerze 10 aplikacji lub 10 instancji tej 
samej aplikacji - mamy 10 singletonów.

Czy robię jakiś błąd myślowy?

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | pl.comp.lang.php

csiph-web