[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]

Dokładnie jak kolega wyżej pisze. Twoje zastosowanie abstract w sumie działa, ale nie jest do końca zgodne z ideą OOP - abstract ma bardziej pełnić rolę interfejsu, tyle że "rozbudowanego" o część metod.

Dzięki temu można np. stworzyć kolekcje obiektów o jednolitym interfejsie i np. po nich potem iterować.

Użycie klasy abstract w sposób jaki tutaj proponujesz jest niewłaściwe - mike podał ci eleganckie rozwiązanie zgodne z ideą OOP.

[MiChaSSs]

Abstract służy do tego żeby nie można było bezpośrednio z tej klasy stworzyć instancji obiektu, a nie do tego żeby nie trzeba było mieć instancji obiektu, jak sama nazwa wskazuje określa to abstrakcyjny model, którego instancja fizyczna nie istnieje. Pozwala to natomiast tworzenie konkretnych instancji obiektów danego typu np:

abstract class Animal {}
class Dog extend Animal {}
class Cat extend Animal {}

&&

Dokładnie jak kolega wyżej pisze. Twoje zastosowanie abstract w sumie działa, ale nie jest do końca zgodne z ideą OOP - abstract ma bardziej pełnić rolę interfejsu, tyle że "rozbudowanego" o część metod.

Dzięki temu można np. stworzyć kolekcje obiektów o jednolitym interfejsie i np. po nich potem iterować.

Użycie klasy abstract w sposób jaki tutaj proponujesz jest niewłaściwe - mike podał ci eleganckie rozwiązanie zgodne z ideą OOP.

Tak, ja tylko tłumaczyłem co miałem na myśli pisząc wcześniej o abstract (IMG:style_emoticons/default/winksmiley.jpg) Ale jak kolega mike zauważył po tym można dziedziczyć + konsekwencje tego, stąd pozostaje tylko to, co mike zaproponował wcześniej, pozdrawiam MD