2017-06-29 3 views
0

Comment surcharger les méthodes de classe enfant en PHP en respectant les principes OOP et SOLID, quand la signature de la méthode doit changer. Il y a un motif de conception destiné à cela?Comment surcharger les méthodes de classe enfant en PHP, en respectant les principes OOP et SOLID, quand la signature de la méthode doit changer?

<?php 

class Client extends People 
{ 
    protected function fillData(ClientDTO $clientDTO) 
    { 
     parent::fillData($clientDTO); 
     ... 
    } 
} 

class People 
{ 
    protected function fillData(PeopleDTO $peopleDTO) 
    { 
     ... 
    } 
} 

class ClientDTO extends PeopleDTO 
{ 
    protected $orders; 
} 

class PeopleDTO 
{ 
    protected $name; 
} 

?> 
+1

Si la signature de méthode change, alors l'enfant ne surcharge pas la méthode parent; c'est créer une nouvelle méthode. – sorayadragon

+1

réponse courte: vous ne pouvez pas, parce que ce que vous voulez est une classe différente et pas un sous-type spécialisé –

+0

Un modèle ici pourrait être le [motif d'usine abstrait] (https://en.wikipedia.org/wiki/Abstract_factory_pattern), mais c'est peut-être (probablement) exagéré pour ce que vous aimeriez accomplir. C'est un modèle plus grand et plus difficile à saisir. Il vous permet de gérer différentes familles de classes qui partagent la même interface (d'où le résumé). Juste commentant que vous avez demandé un modèle. – hakre

Répondre

1

Je vous inquiétez pas ici de changer une signature de méthode, parce que les signatures sont compatibles dans votre cas particulier, tant que ClientDTO est une sous-classe de PeopleDTO. Vous pouvez passer ClientDTO par exemple à People::fillData et cela fonctionnera toujours. Donc, je dirais, pas de soucis de ce point de vue. Mais vous devez utiliser des interfaces à la place des dépendances de classes codées en dur dans vos signatures. Vous pouvez l'appeler un modèle de stratégie si vous voulez. De cette façon, vous respecterez les principes Open \ Closed et Dependency Inversion, puisque vos classes dépendront des abstractions. Ou au moins, vous devriez utiliser une classe abstraite de base si vous pensez que la création d'interfaces serait trop lourde ou que vos entités sont très spécifiques à un domaine.

P.S. Je suppose que vous avez fait une erreur dans votre exemple de code: class ClientDTO doit être class PeopleDTO

+0

Bien sûr, j'ai fait une erreur dans votre exemple de code: class ClientDTO devrait être de la classe PeopleDTO – malheirosrafa