2011-01-14 27 views
13

Mam kilka funkcji dotyczących plików cookie. Czy byłoby strasznym pomysłem pogrupowanie ich poprzez przeniesienie ich do klasy i użycie ich jako metod statycznych?Funkcje a metody statyczne

Funkcje:

function cookie_get(){} 
function cookie_set(){} 
function cookie_delete(){} 

statyczne metody:

class cookie 
{ 
    static function get(){} 
    static function set(){} 
    static function delete(){} 
} 
+2

Wystarczy mieć świadomość zwykłych „klas statycznych/singletons są wrogiem testów jednostkowych” problemów, które mogą wystąpić. –

Odpowiedz

8

Tak, to byłby straszny pomysł, ponieważ static methods are hard to test and mock. Dlaczego nie wystarczy utworzyć prawdziwą klasę Cookie, którą można skonfigurować w środowisku wykonawczym, używając tych metod jako zwykłych metod.

Jeśli chcesz tylko zgrupować te funkcje w pakiet, możesz równie dobrze use Namespaces.


Edit: Ponieważ przyniósł go w komentarzach: tak, w celach testowych regularne funkcje są nietestowalna jak statyki. Tak więc twoja początkowa sytuacja jest tak "straszna", jak zmiana jej na klasę statyczną. Nawet pseudo przestrzeni nazw nie daje żadnej korzyści, ponieważ już to zastosowałeś do swoich zwykłych funkcji. cookie_get jest tak samo dobry lub zły, jak Cookie::get.

+1

+1 za dodanie w referencji. Dobrze wiedzieć. – karim79

+2

To zbyt złe przestrzenie nazw są niedostępne do czasu PHP 5.3. –

+0

@Emanuil [PHP 5.2 oficjalnie osiągnęło koniec wsparcia od 16 grudnia 2010 r.] (Http://www.php.net/archive/2010.php#id2010-12-16-1). [Wszyscy użytkownicy są zachęcani do aktualizacji do wersji 5.3.] (Http: //de2.php.net/migration53) – Gordon

10

To byłby świetny pomysł, pod warunkiem, że są w pełni świadomi caveats involved. Jest to znane jako Utility Pattern:

Dobrymi kandydatami do klas użytkowych są metodami typu convenience, które mogą być zgrupowane razem funkcjonalnie.

+2

Dzięki, to świetnie wiedzieć. Zastanawiam się jednak, dlaczego nie używają natywnych funkcji PHP. Dlaczego 'str_replace()' nie jest 'str :: replace()'? –

+3

PHP jest językiem proceduralnym, a funkcje OOP są traktowane jako refleksja. Chodzi przede wszystkim o wbudowane funkcje (z wysoce niespójnymi konwencjami nazewnictwa) w przeciwieństwie do statycznych klas pomocniczych, które grupują powiązane funkcje. – karim79

+0

@EmanuilRusev Rdzeń API PHP jest ogólnie słabo zaprojektowany, ale zwłaszcza jeśli chodzi o przestrzenie nazw, ponieważ były niedostępne do czasu stosunkowo niedawnej wersji PHP5. Forma str :: replace() byłaby zdecydowanie preferowana, ale mam poważne wątpliwości, czy ktokolwiek z mocą wsteczną doda je do rdzenia w dowolnym momencie w najbliższej przyszłości. –

9

Właściwie dobrą praktyką jest organizowanie takich funkcji. Nowoczesną alternatywą byłoby użycie namespace.

3

To byłby świetny sposób na uporządkowanie kodu, ale po co używać funkcji statycznych, po prostu stwórz klasę dla wymaganej funkcjonalności.

Albo, jak wspomniano powyżej, użyj przestrzeni nazw, ale nie jestem szczególnie zaznajomiony z ich zaletami/wadami.

$cookie->get() jest ładniejszy pracować niż cookie_get() moim zdaniem