2017-10-21 128 views
-1

Aidez-moi s'il vous plaît. J'ai besoin d'une meilleure compréhension des principes PHP OOP.Organiser des classes et des propriétés en PHP - la bonne façon?

Si j'ai une propriété de classe qui est immuable pour toutes les instances de la classe devrait être définie comme statique? Si oui, existe-t-il un moyen de s'assurer que les propriétés statiques sont définies dans toutes les classes de ce type? Comme je l'ai lu dans le manuel PHP, les propriétés statiques ne peuvent être contrôlées ni par l'interface ni par les classes abstraites. Ou ai-je tort?

exemple simple.

<?php 

// Parent class 
abstract class Employee 
{ 
    abstract public function getAlias(); 
} 

// Child classes 
class Manager extends Employee 
{ 

    public function getAlias() 
    { 
     return 'manager'; 
    } 
} 
class Security extends Employee 
{ 
    public function getAlias() 
    { 
     return 'security'; 
    } 
} 

Dites-moi, où une propriété alias doit être placé? Je dois être sûr que tous les descendants d'employés qui seront créés à l'avenir auront cette propriété définie. Est-il acceptable de conserver ce type de propriétés dans des méthodes dynamiques? Ou ils devraient être placés dans des constantes, des méthodes statiques ou des propriétés statiques?

+0

Pouvez-vous expliquer un peu, ce que vous avez l'intention d'utiliser l'alias? – Gordon

+0

Par exemple, la propriété 'alias' (autant que toute autre similaire) peut être stockée dans la table DB et utilisée pour l'héritage de table unique - instancier une classe appropriée basée sur l'alias des enregistrements de base de données récupérés. – Roman

+0

vous pourriez simplement utiliser le nom de classe réel au lieu d'un alias dans ce cas. 'Manager :: class' vous donnerait le nom de classe complet. De plus, votre ORM ne devrait-il pas gérer cela pour vous? Ne vous méprenez pas. C'est une question valide. Ça sent juste comme quelque chose qui pourrait ou devrait être géré par la vérification de type à la place. Mais pour décider cela a besoin de contexte. – Gordon

Répondre

0

En fait, la version actuelle est tout à fait ok (si elle est considérée sans contexte), car elle rend un code plus propre, car il correspond plus étroitement principle of least astonishment. Techniquement, vous pouvez réécrire comme cela (mais ce serait en fait aggraver le code):

abstract class Employee { 
    public function getAlias() { 
     return $this->alias; 
    } 
} 

class Manager extends Employee { 
    protected $alias = 'mngr'; 
} 


$user = new Manager; 
echo $user->getAlias(); 

Code en direct: https://3v4l.org/sjVOT

L'aspect le plus important est le but de ce code. Vous avez mentionné, que vous voudriez utiliser quelque chose comme ceci pour traiter l'héritage de table unique, mais voici la partie importante:

Vos entités de domaine ne devraient pas savoir comment votre couche de persistance fonctionne.

et en tirant des informations structurales de la couche de domaine pour une utilisation dans certains constructeur de requête est une très mauvaise idée. Je recommande pour vous à la place au motif data mapper (vous devriez probablement lire le livre PoEAA).

Vos entités de domaine ne devraient pas connaître tous les détails sur la façon dont (ou même « si »), ils sont en cours d'enregistrement ou restaurés.