2010-06-19 23 views
2

Y a-t-il des raisons pour lesquelles je ne devrais pas créer une classe finale avec des méthodes statiques pour éviter que certaines fonctions internes soient appelées?Utiliser une classe comme espace de noms

final class ModuleGlobalFunctions { 
    static public function generateWord { 
    $result = ''; 

    while (strlen($result) < 12) { 
     $result = self::generateSyllable(); 
    } 

    return $result 
    } 

    static private function generateSyllable() { 
    // Generates a random syllable. 
    // … 
    } 
} 

$word = ModuleGlobalFunctions::generateWord(); 

// It raises an error. 
$syllable = ModuleGlobalFunctions::generateSyllable(); 

Répondre

2

Eh bien, personnellement, je recommanderais d'utiliser des classes pour grouper une logique similaire. Donc dans votre cas (l'exemple que vous avez fourni), c'est une bonne idée. Comme pour final, c'est un toss up. Je préfère utiliser résumé pour éviter l'instanciation (puisque PHP ne supporte pas statiques classes). Si vous utilisez final, je suggère d'ajouter un constructeur privé pour empêcher l'instanciation: private function __construct() {} ...

Personnellement, j'aime le concept de le garder statique. La raison est triple. D'abord, c'est plus facile sur la mémoire (puisqu'il n'y a aucune instance à suivre). Deuxièmement, c'est plus rapide (un appel de méthode statique est plus rapide qu'un appel de méthode d'instance). Troisièmement, et plus important encore, cela a du sens. Les instances ont un état (c'est pourquoi elles sont des instances). Est-ce que votre classe a besoin d'un état? Si oui, utilisez une instance. Si non, c'est exactement ce que classes

Comme pour passer une instance comme Sjoerd le mentionne, vous pouvez le faire avec des classes statiques (et être réellement moins couplé qu'avec des instances). Voici la raison. Sauf si vous avez besoin d'une interface ou d'un héritage (et que vous en vérifiez), vous n'avez aucune idée si l'objet implémente réellement la méthode generateWord(). Mais, si vous passez un rappel, peu importe comment la méthode est accédée (ou sa construction sous-jacente), tout ce qui importe est qu'elle a la même syntaxe (ou similaire) (en ce qui concerne les paramètres et les valeurs de retour). Maintenant, les interfaces sont une meilleure solution à cela (car elle impose l'interface), mais elles nécessitent une compréhension assez profonde de la POO pour que la conception soit correcte. Dans un pincement, un rappel fonctionnera très bien pour ce cas ...

+0

L'argument le plus rapide est très faible; la différence est très faible: http://codepad.viper-7.com/dhL1dK – Artefacto

+0

L'argument mémoire est faible pour la même raison. – Sjoerd

3

Création d'une classe pour protéger de fonctions privées est une bonne idée. De cette façon, une méthode publique de la classe peut appeler une méthode privée, sans rendre la méthode privée invocable depuis l'extérieur de la classe.

Faire une classe final est également une bonne idée, car cela indique que la classe n'a pas été conçue en pensant à la surcharge et simplifie la classe.

Rendre la classe statique est une mauvaise idée, car elle couple étroitement l'appelant à la classe. Si vous appelez Test :: generateWord(), vous utiliserez toujours la classe Test. Cependant, si vous utilisez $ test-> generateWord(), vous pouvez passer dans une autre classe, ce qui crée d'autres mots. Cela facilite le changement du logiciel et facilite le test unitaire.