2009-07-29 8 views
0

J'ai créé un objet d'affichage qui contient l'en-tête, barre latérale et le pied de page:Est-ce mauvais objet orienté PHP?

class Display { 
    protected $framework; 
    public $mysql; 
    public function __construct() { 
     $this->mysql = new MySQL(); 
     $this->framework .= $this->header(); 
     $this->framework .= $this->body(); 
     $this->framework .= $this->sidebar(); 
     $this->framework .= $this->footer(); 
    } 
    private function header(){ /* blah */ } 
    private function body(){ } 
    private function sidebar(){ /* blah */ } 
    private function footer(){ /* blah */ } 
    public function displayPage(){ 
     print $this->framework; 
    } 
} 

Sur chaque page j'ai créé un objet qui étend l'objet d'affichage, avec le code pour le corps:

class IndexPHP extends Display { 
    public function body(){ 
     $this->user = new User(); 
     return '<div class="body">Hello ' . $this->user->getName() . '</div>'; 
    } 
} 
$page = new IndexPHP(); 
$page->displayPage(); 

Ai-je créé un problème en imbriquant trop les objets? Par exemple, dans l'objet Utilisateur, comment accéder à l'objet MySQL déjà initié?

class User { 
    protected $name; 
    public function __construct() { 
     $this->id = /* MySQL object query here */ 
    } 
} 

Répondre

7

Le problème avec l'approche que vous avez donnée est que vous ne suivez aucune sorte de principe de «séparation des pouvoirs». Votre objet Display contient une base de données avec la logique de connexion; ce n'est probablement pas la meilleure approche ("l'objet de Dieu"). Cela peut être une meilleure idée de suivre les principes MVC (model-view-controller), où vous avez une classe qui connaît quelque chose sur votre modèle (base de données), une autre qui sait comment transformer le modèle en objets qui seront présentés , et le troisième qui montre réellement les données avec tout son bonté CSS (voir, souvent juste un fichier de modèle PHP).

Je vous recommande de jeter un oeil à un cadre MVC existant - J'utilise QCubed (http://qcu.be), il y en a d'autres - Symfony, Zend, CakePHP. Ils vous offrent tous un excellent moyen de séparer votre code proprement, ce qui se traduit finalement par la maintenabilité.

+0

Je ne pense pas que ce soit mauvais. Il a juste besoin de passer les dépendances de l'extérieur. – troelskn

+1

C'est impossible à maintenir. Cela fonctionnerait bien pour un petit projet de jouet, mais je ne livrerais pas de code comme celui-ci pour un système de production. –

+0

Merci d'avoir pris le temps de commenter. Je suis nouveau à OOPHP, donc les conseils aident vraiment. – timborden

1

Par exemple, dans l'objet Utilisateur, comment accéder à l'objet MySQL déjà initié?

Vous passez dans le constructeur:

class User { 
    protected $name; 
    public function __construct($mysql) { 
    $this->id = $mysql->something(); 
    } 
} 
+0

Droit .... Je pense que je vais essayer d'aplatir les choses un peu .... Je suppose que l'imbrication et les objets ne se mélangent pas bien. Merci – timborden

0

Si vous surchargent des fonctions dans les classes d'enfants (par exemple votre classe IndexPHP remplace body()), vous devriez les faire protected au lieu de private.

De plus, il est recommandé de ne faire que des choses simples, comme affecter des valeurs, dans le constructeur. Votre constructeur Display fait tout le travail dans la classe, il pourrait être préférable de déplacer les travaux de construction à displayPage:

public function __construct(MySQL $mysql) { 
    $this->mysql = $mysql; 
} 

public function displayPage($rebuild=false) { 

    if(empty($this->framework) || $rebuild) { 
     $this->framework = $this->header(); 
     $this->framework .= $this->body(); 
     $this->framework .= $this->sidebar(); 
     $this->framework .= $this->footer(); 
    } 
    print $this->framework; 
} 
Questions connexes