2011-01-14 9 views
13

Tengo algunas funciones relacionadas con las cookies. ¿Sería una idea horrible agruparlos moviéndolos a una clase propia y usarlos como métodos estáticos?Funciones frente a métodos estáticos

Funciones:

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

Los métodos estáticos:

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

acaba de ser conscientes de las habituales "clases estáticas/hijos únicos son el enemigo de la unidad de pruebas" problemas que pueden surgir. –

Respuesta

8

Sí, eso sería una idea horrible porque static methods are hard to test and mock. ¿Por qué no crear una clase de Cookie real que pueda configurar en tiempo de ejecución con esos métodos como métodos regulares?

Si solo desea agrupar esas funciones en un paquete, puede hacerlo también use Namespaces.


Editar: Ya que sacado el tema en los comentarios: sí, para fines de pruebas de funciones regulares son tan indemostrable como estática. Entonces su situación inicial es tan "horrible" como cambiarla para usar una clase estática. Incluso el pseudo espacio de nombres no te da ninguna ventaja, porque ya lo aplicaste también a tus funciones habituales. cookie_get es tan bueno o malo como Cookie::get.

+1

+1 para agregar en la referencia. Bueno saber. – karim79

+2

Es demasiado malo espacios de nombres no están disponibles hasta PHP 5.3. –

+0

@Emanuil [PHP 5.2 oficialmente ha llegado al final del soporte desde el 16 de diciembre de 2010] (http://www.php.net/archive/2010.php#id2010-12-16-1). [Se recomienda a todos los usuarios actualizar a PHP 5.3.] (Http: //de2.php.net/migration53) – Gordon

10

que sería una gran idea, siempre y cuando esté plenamente consciente de la caveats involved. Esto se conoce como la Utility Pattern:

Los buenos candidatos para clases de utilidad son métodos de conveniencia que puede ser agrupados juntos funcionalmente.

+2

Gracias, eso es bueno saberlo. Me pregunto, sin embargo, por qué las funciones nativas de PHP no lo usan. ¿Por qué 'str_replace()' no es 'str :: replace()'? –

+3

PHP es un lenguaje de procedimiento, con características de OOP añadidas como una ocurrencia tardía. Se trata de funciones incorporadas (con convenciones de nomenclatura altamente inconsistentes) en oposición a las clases de ayuda estática que agrupan funciones relacionadas entre sí. – karim79

+0

@EmanuilRusev El núcleo API de PHP está mal diseñado en general, pero especialmente cuando se trata de espacios de nombres porque no estaban disponibles hasta la versión relativamente reciente de PHP5. La forma str :: replace() sería definitivamente preferible, pero dudo seriamente de que alguien los agregue retroactivamente al núcleo en cualquier momento en el futuro cercano. –

9

En realidad, es una buena práctica organizar funciones como esa. Una alternativa moderna sería usar un namespace.

3

Esa sería una gran manera de organizar su código, pero ¿por qué usar funciones estáticas ?, simplemente haga una clase para la funcionalidad requerida.

O como dije anteriormente uso espacios de nombres, pero no estoy particularmente familiarizado con los pros/contras de ellos.

$cookie->get() es más agradable trabajar con que cookie_get() en mi opinión

Cuestiones relacionadas