Discussion :

[mapmip]

Bonjour,

dans le cadre de la POO, comment faites vous pour choisir la portée de vos méthodes (private/public/protected) ?
Pourquoi vous choisissez un protected plutot qu'un public, existe-t-il des règles/best practices,etc pour faire nos choix ?


Merci d'avance

[grunk]

Si tu as compris la signification des différentes portée , tu ne devrais pas te poser la question

Private si la méthode n'est appelé que par les mécanismes internes de la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
class Test{
	public function __construct(){
		$this->myPrivate();
	}
 
	private function myPrivate(){
 
	}
}

Protected si cette méthode peux être appelée dans les mécanisme interne d'une classe fille

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Test{
	public function __construct(){
		$this->myPrivate();
	}
 
	private function myPrivate(){
 
	}
 
	protected function myProtected(){
 
	}
}
 
class Fille extends Test{
	public function __construct(){
		$this->myPrivate(); // Erreur
		$this->myProtected(); // OK
	}
}

Public si la méthode à besoin d'être appelée en dehors de la classe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$test = new Test();
$test->myPublic();

[mapmip]

merci je connaissais les mécanismes,
mais la question c'est pourquoi choisit-on telle ou telle portée ?
Y a t il des règles dans la conception logicielle, des recettes ?

[Lokicoule]

Private si la méthode n'est appelé que par les mécanismes internes de la classe :

Protected si cette méthode peux être appelée dans les mécanisme interne d'une classe fille

Public si la méthode à besoin d'être appelée en dehors de la classe :

Encapsulation
Dans un premier temps tu peux déclarer tes fonctions comme étant publiques et par la suite en modifier la portée en te basant sur les appelles effectuées dans ton projet.
Tu t'apercevras alors, que ça sera à toi de mieux préparer ton brouillon (mental ) avant de commencer à coder une nouvelle classe, car c'est juste de la logique.

[grunk]

Dans un premier temps tu peux déclarer tes fonctions comme étant publiques et par la suite en modifier la portée

Surtout pas , c'est le meilleur de laisser public des méthode qui ne devrait pas l'être car on à oublié de la repasser dans la bonne portée.

mais la question c'est pourquoi choisit-on telle ou telle portée ?

C'est en fonction du besoin. Y'a pas de règles particulière si ce n'est de ne pas mettre en public ce qui peut être privé

Après c'est plus délicat entre privé et protected car la notion d'héritage rentre dans l'équation.

Si tu as une classe qui te pose problème montre là nous et on pourra te dire pourquoi telle ou telle portée.

[mapmip]

je ne suis pas actuellement en cas pratique,
je suis sur du théorique pur, je me tiens
au courant des dernières nouveautés sur php poo,
en conception logiciel, etc

[Lokicoule]

Effectivement ce n'est pas la meilleure des solutions à court, moyen, ou long terme, mais je persiste à dire que c'est une solution pédagogique, qui aide justement à appréhender le concept de portée.

[Tsilefy]

Si tu réflechis en termes de stabilité et de maintenance de code (avec pour objectif de changer le code le moins possible), une méthode publique est un contrat que tu fais: tu garantis à l'utilisateur (le plus souvent à toi-même) que cette méthode ne changera pas, qu'on pourra toujours utiliser cette méthode tant que la version majeure de l'application ne change pas. Pour renforcer ce contrat, tu peux même mettre ces méthodes dans l'interface de la classe.

Les méthodes protégées/privées, elles, peuvent changer du jour au lendemain, peu importe.

Ça garantit que tu n'auras pas besoin de réécrire toutes les instances où cette méthode est utilisée dans ton application à chaque fois que tu modifies cette classe, ou de vérifier si l'usage de la méthode est toujours appropriée.

Vu sous cet angle, ça te donne un confort certain dans ton code.

[grunk]

Oui et non car le corps de ta méthode peux changer (par exemple améliorer un algo) sans pour autant impacter l'utilisation finale de la fonction tant que les paramètres d'entrée et le retour sont les mêmes.
Mais effectivement il faut bien garder à l'esprit qu'une méthode public à un impact bien plus important qu'une méthode privée.

[ABCIWEB]

mais la question c'est pourquoi choisit-on telle ou telle portée ?
Y a t il des règles dans la conception logicielle, des recettes ?

On comprend mieux cela dans l'optique d'une utilisation de la classe par des personnes qui ne l'ont pas conçue (ou qui ont oubliés sont fonctionnement...)
Les méthodes publiques sont conçues pour configurer la classe et apporter des fonctionnalités sans qu'il soit possible de compromettre le fonctionnement de la classe. Ainsi on fait souvent une méthode "getter" public pour récupérer la valeur d'une propriété privée. Si on avait simplement passer la propriété privée en propriété public (pour éviter le getter) on pourrait définir également la valeur de cette propriété et pas seulement la récupérer, ce qui pourrait compromettre le fonctionnement de la classe. C'est donc utile pour éviter des erreurs d'utilisation de la classe.

[Nightfall]

public ou private le choix est assez facile en général : avec private la fonction ne sert qu'en interne donc c'est de la réutilisation de code à l'intérieur de la classe, alors que les méthodes public c'est ce qui permet d'utiliser la classe depuis l'extérieur.

protected ou private c'est plus délicat mais si tu sais que tu ne vas pas créer de classe dérivée, pas besoin de protected. Si tu peux avoir des classes dérivées, ça revient à se demander si le comportement de la méthode doit pouvoir être redéfini par une classe dérivée. Est-ce que tous les objets vont se comporter de la même façon à ce niveau ou pas ?

Pour te guider dans la poo tu as solid : http://fr.wikipedia.org/wiki/SOLID_%28informatique%29

[Tsilefy]

Oui et non car le corps de ta méthode peux changer (par exemple améliorer un algo) sans pour autant impacter l'utilisation finale de la fonction tant que les paramètres d'entrée et le retour sont les mêmes.
Mais effectivement il faut bien garder à l'esprit qu'une méthode public à un impact bien plus important qu'une méthode privée.

Oui, je parlais effectivement de la signature de la méthode (paramètres + retour), qu'il vaut mieux garder le plus stable possible.

[mapmip]

Quand une variable ou une fonction est protected dans la classe mère,
depuis la classe fille, pour appeler une fonction protégée, doit-on l'appeler ainsi parent::mafunctionprotege
pour récuperer la fonction au niveau de la classe mère et $this->mafunctionprotege pour récuperer la fonction au niveau de l'objet de la classe fille ?
?

[grunk]

Un élément protected dans la classe mère est utilisable dans la classe fille comme si il en faisait partie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class Mere{
    protected function bonjour(){
		return 'Bonjour';
	}
}
class Fille extends Mere{
	public function test(){
		echo $this->bonjour();
	}
}

[Tsilefy]

Je suppose que mapmip veut parler du cas où la classe fille redéfinit la méthode. Dans ce cas, oui, parent:: est la bonne technique.
http://php.net/manual/fr/keyword.parent.php