Mam nieduże doświadczenie w OOP. Pojawiło mi się takie pytanie: kiedy używac klasy z
samymi statycznymi metodami a kiedy wzorca sigleton? W swoim programie mam taki
dylemat przy klasach Database i Logger.

do góry

Dnia 13-07-2012 o 20:10:10 <j...@p...onet.pl> napisał(a):

> Mam nieduże doświadczenie w OOP. Pojawiło mi się takie pytanie: kiedy
> używac klasy z samymi statycznymi metodami a kiedy wzorca sigleton? W
> swoim programie mam taki dylemat przy klasach Database i Logger.

singleton ma normalny konstruktor, Klasa, zależnie od języka, biedny albo
wcale, jeśli potrzebujesz się połączyć do bazy czy otworzyć plik logu, to
czemu nie zrobić tego w konstruktorze singletona?

--
Jordan Szubert

do góry

On Fri, 13 Jul 2012 21:55:20 +0200, "Jordan Szubert"
<u...@j...us.to> wrote:

>Dnia 13-07-2012 o 20:10:10 <j...@p...onet.pl> napisał(a):
>
>> Mam nieduże doświadczenie w OOP. Pojawiło mi się takie pytanie: kiedy
>> używac klasy z samymi statycznymi metodami a kiedy wzorca sigleton? W
>> swoim programie mam taki dylemat przy klasach Database i Logger.
>
>singleton ma normalny konstruktor, Klasa, zależnie od języka, biedny albo
>wcale, jeśli potrzebujesz się połączyć do bazy czy otworzyć plik logu, to
>czemu nie zrobić tego w konstruktorze singletona?

Dlatego ze konstruktor sluzy, jak sama nazwa wskazuje, do
konstruowania

A.L.

do góry

On 2012-07-13 20:10, j...@p...onet.pl wrote:
> Mam nieduże doświadczenie w OOP. Pojawiło mi się takie pytanie: kiedy używac klasy
z samymi statycznymi metodami a kiedy wzorca sigleton? W swoim programie mam taki
dylemat przy klasach Database i Logger.

- statycznych metod nie można przedefiniować w klasie pochodnej
- testowanie takiego kodu to PITA, w singletonie można dodać setter i
podmieniać implementację na jakiś mock

--
MB

do góry

W dniu piątek, 13 lipca 2012 20:10:10 UTC+2 użytkownik (Nieznane) napisał:

> Mam nieduże doświadczenie w OOP. Pojawiło mi się takie pytanie: kiedy używac klasy
z samymi statycznymi metodami a kiedy wzorca sigleton?

Singleton ma sens wtedy, gdy obiekt ma implementować zadany interfejs. Wtedy
singleton zwraca jeden egzemplarz obiektu klasy pochodnej.
Jak często taka sytuacja występuje? Trudno powiedzieć. Przykładem z biblioteki
standardowej są obiekty cin, cout i cerr, które istnieją w jednym egzeplarzu i
realizują interfejsy istream/ostream.
Dobrym przykładem mogą być też różne biblioteki do logowania, gdzie jest jakiś
interfejs loggera i jakaś funkcja, która zwraca ten "jeden jedyny" (np. root logger
albo jak go tam nazwiemy), co nie wyklucza też istnienia wielu innych,
implementujących ten sam interfejs.

Natomiast jeśli nie ma potrzeby realizowania zadanego interfejsu, to singleton tylko
plącze się między nogami. Funkcje statyczne też się plączą. Napisz po prostu funkcję,
której implementację umieścisz w osobnym pliku a jej stan zdefiniujesz w nienazwanej
przestrzeni nazw. Coś takiego:

// counter.h:
int getNextValue();


// counter.cpp:
namespace
{
int nextValue = 0;
}

int getNextValue() { return nextValue++; }


I tyle.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

Maciej Sobczak <s...@g...com> wrote:

> // counter.cpp:
> namespace
> {
> int nextValue = 0;
> }

Dlaczego tak, a nie static int nextValue?

--
Gof
http://www.chmurka.net/

do góry

W dniu sobota, 14 lipca 2012 11:09:23 UTC+2 użytkownik Adam Wysocki napisał:

> &gt; // counter.cpp:
> &gt; namespace
> &gt; {
> &gt; int nextValue = 0;
> &gt; }
>
> Dlaczego tak, a nie static int nextValue?

Słowo kluczowe static jest zdecydowanie za bardzo przeciążone. To, że w tym przypadku
efekt byłby zgodny z oczekiwaniem nie znaczy, że jest to efektywna metoda. Czy gdyby
tych zmiennych było więcej, nadal chciałbyś przy każdej z nich pisać static?
Przestrzeń nazw jest bardziej kulturowo zbliżona do reszty - zbiera kilka rzeczy w
jedną grupę i w ten sposób podpowiada czytelnikowi: "hej, te rzeczy robią coś razem".
W tym przypadku ta grupa to stan modułu. Akurat moduł wyszedł banalny, ale w
praktycznym przykładzie pewnie będziesz chciał mieć tam również mutex. Albo pincet
innych rzeczy, które *razem* coś robią. To "razem" to właśnie zakres przestrzeni
nazw.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry