Forum PHP.pl

Helpery to klasy ze statycznymi metodami możesz zrobić taką klasę tylko z jedną metodą.

A niby dlaczego tylko z jedną metodą? Poza "helperami" masz też klasy narzędziowe. Jedna metoda na klasę to bezmyślność.
Ale jednak nie da się ich uniknąć kiedy piszesz aplikację w duchu OOP.
Klasy narzędziowe to normalna sprawa, czasem są potrzebne i nie należy ich za wszelką cenę unikać.

Klasa narzędziowa to dobre wyjście, jeśli tego faktycznie potrzebujesz. Jedyne co możesz zrobić dodatkowo to zamknąć ją na rozszerzanie i zablokować możliwość tworzenia instancji.

[PHP] pobierz, plaintext 
<?php /* już nie pamiętam czy w PHP jest final */ final class Tools {
 
    private Tools() {
        throw new Exception("IllegelStateException");
    }
 
    // Jakieś funkcje
}
 
?>
[PHP] pobierz, plaintext 

Ten post edytował mike 30.11.2010, 09:45:38

W symfony mamy funkcje typu include_partial() ktore w pewnym sensie tez sa helperami...wedlug mnie takie maja dzialanie poprostu zamykasz w funkcji/klasie czesto wykonywane czynnosci lecz niezbyt rozbudowane.

p.s oczywiscie jesli w klasie to jako metody statyczne

Ten post edytował marcio 30.11.2010, 12:35:36

Z funkcjami jest taki problem, że nie podlegają automatycznemu ładowaniu. Tutaj funkcjonalność OOP jest tylko narzędziem do uzyskania żądanych efektów, czyli funkcji + automatycznego ładowania.

Reasumując: biorąc pod uwagę ograniczenia PHP (właśnie podane przez zyx'a) nie jest złym rozwiązaniem wrzucenie do klasy funkcji statycznych i niejako traktować klasę jak przestrzeń nazw.

Tak btw, jak masz dobrze zaprojektowany kod, to sytuacja w której chcesz utworzyć klasę Tools tylko ze statycznymi funkcjami nie ma prawa zaistnieć.

Zgodzę się z użytkownikiem aart3k na prawie całej linii. Dobrze zaprojektowany model nie potrzebuje przestrzeni narzędzi. Jednak tak się czasem zdarza, że chcemy sobie różne rzeczy uprościć z punktu widzenia programistycznego obciążająć serwer. Dobrym przykładem jest tutaj helper Form z framework Symfony. Masz tam kupę funkcji generujących tylko i wyłącznie kod HTML, który bądź co bądź powinieneś generować samemu. A jednak w pewnych warunkach (np. dopuszczenie do szablonów php grafka) wymaga się takich a nie innych operacji. Wszystko zależy nie tylko od efektu jaki chcesz uzyskać, ale również od warunków. Ogólnie powtórze jak echo po aart3k: Dobrze zaprojektowany model nie potrzebuje takiego typu klas narzędziowych jak opisujesz.

Hmmm... faktycznie brak autoloadera to już poważna wada (to nie jest ironia tylko przyznanie racji).

Ma prawo i takie coś jest powszechnie stosowane. Oczywiście można każdorazowo tworzyć nową instancję na zasadzie:

[PHP] pobierz, plaintext 
$text = new StringUtils()->doSth($text); // PHP 5.4
 
$stringUtils = new StringUtils();
$text = $stringUtils->doSth($text); // PHP < 5.4
[PHP] pobierz, plaintext 

Albo utworzyć sobie jakiś obiekt-kolekcję dla tego typu klas, który zwróci nam jedną automatycznie zainicjalizowany obiekt:

[PHP] pobierz, plaintext 
$text = $this->getUtilClass('String')->doSth($text);
[PHP] pobierz, plaintext 

Ale skorzystanie z metod statycznych jest po prostu dużo wygodniejsze i czytelniejsze.

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.

Może więc aart3k chodzi Ci o system helperów z Kohany? Bo nie wiem czy dobrze zrozumiałem. Podam przykład jednego z wbudowanych helperów Kohany:

[PHP] pobierz, plaintext 
class security_Core {
 
	public static function xss_clean($str)
	{
		return Input::instance()->xss_clean($str);
	}
 
	public static function strip_image_tags($str)
	{
		return preg_replace('#<img\s.*?(?:src\s*=\s*["\']?([^"\'<>\s]*)["\']?[^>]*)?>#is', '$1', $str);
	}
 
	public static function encode_php_tags($str)
	{
		return str_replace(array('<?', '?>'), array('&lt;?', '?&gt;'), $str);
	}
 
}
[PHP] pobierz, plaintext 

które wywołuje się statycznie nazwa_helpera::nazwa_metody(parametry)
Oczywiście w Kohanie nie istnieje jeden taki worek, ale takich klas jest wiele, zazwyczaj w sensowniejsze grupy poukładana. Jak zauważono, dobrze napisany skrypt nie potrzebuje ich, ale nieraz zamiast pisać kod od razu "ciurkiem" od razu poprawnie, wygodniej sobie takie klasy zdefiniować, by nie powtarzać co i rusz tego samego kodu, wielokrotnie długiego. Widząc niektóre jednak można się śmiać (patrząc na helper Array zobaczyć można ile to wywołania wariacji array_push/pop/shift czy innych wbudowanych), ale dla nie sięgających głębiej w bebechy frameworka takie pomocne dodatki są wybawieniem. Sam nieraz sobie pisze takie by przykładowo zamiast kilkunastu linijek kodu zgrabnie kod ująć jednym wywołaniem.

Po klasie abstrakcyjnen można odziedziczyć i wtedy utworzenie instancji stoi otworem.
Zrób klasę finalną z prywatnym konstruktorem, z którym rzucisz wyjątek tak jak pokazałem w poprzednim poście.
Można.