[OOP] Klasa tylko z funkcjami statycznymi Opcje

[MiChaSSs]

Hej,
Ostatnio zacząłem przepisywać skrypt na OOP i mam kilka funkcji (nie powiązanych ze sobą), które nie nadają się do standardowej klasy (gdzie tworzy się instancje obiektu) i tak sobie myslałem, czy byłoby prawidłowo jeślibym utworzył klasę (np. Tools czy Utilities) w której trzymałbym przydatne statyczne metody? Czyli stworzyłbym klasę, która nigdy nie będzie miała obiektu a będzie istniała tylko po to, żeby być kontenerem na statyczne metody. Coś na tej zasadzie:

[PHP] pobierz, plaintext 
class Tools
{
        public static function Metoda1()
        {
 
        }
 
        public static function Metoda2()
        {
 
        }
}
 
// Wywołanie metod
Tools::Metoda1();
Tools::Metoda2();
[PHP] pobierz, plaintext 

I teraz mam pytanie do Was ... ma to jakiś sens? (IMG:style_emoticons/default/biggrin.gif) Jakie jest prawidłowe podejście? Czy funkcje powinny "luzem" w kodzie leżeć a ja nie powinienem za wszelką cenę opakowywać wszystkiego w OOP? Pozdrawiam MD

Ten post edytował MiChaSSs 28.11.2010, 22:45:51

[athabus]

Ja mam cały zbiór klas pomocniczych. Nazwałem go Cat - sam już nie pamiętam od czego to był skrót ;-) W nim mam klasy takie jak np.
Cat_Converter_String
Cat_Converter_Price
Cat_Converter_Array

Umieszczam je w każdym praktycznie projekcie, który robię. Np. po co tysiąc razy pisać metodę do przeliczania ceny brutto, naliczania rabatów, czy "slugowania" stringa jak można to umieścić w klasach pomocniczych. Jest to lepsze rozwiązanie, bo oszczędza czas i ogranicza głupie pomyłki.

Umieszczanie wszystkiego w modelu jest imo kiepskim pomysłem. Przykład nie będzie przeliczanie cen netto na ceny brutto - jeśli umieścisz to w modelu np. sklepu internetowego, gdzie robisz takie przeliczenia w wielu miejscach to po pewnym czasie mogą pojawić się niekonsekwencje typu:
- w jednym miejscu zaokrąglasz cenę a w drugim wartość produktów przez co otrzymujesz inne wyniki
- w przypadku dodania rabatu w jednym miejscu będziesz skracał dopiero wynik końcowy a w innym skrócisz raz po obliczeniu rabatu a następnie po obliczeniu ceny brutto - i znowu powstają groszowe niezgodności, które trudno potem wychwycić.

Mając wszystko scentralizowane łatwiej uniknąć takich głupich błędów. Ja osobiście lubię klasy z statycznymi metodami narzędziowymi i często korzystam. Autoloader też jest dla mnie ważny bo upraszcza kod.