De rien ;)

[quote="moogli"]d'ailleurs en t'indiquant cela je pense que tu as une idée pour faire ce que tu voulais ?[/quote]
Bah disons que du coup je vais me confiner à suivre ce modèle de conception, parce que c'est vrai qu'une fois assimilé le système de plugins en découle tout seul...
Et du coup si je pense que (du moins dans mon cas) la majeure partie ou du moins la plus compliquée : la conception de l'architecture du système, est pré-machée. Et ça me laisse un petit arrière goût de frustration :lol:
Ceci dit c'est sûr que pour des applications beaucoup plus complexes, cette remarque est nulle et non avenue !

Mais bon dans tout les cas merci pour votre aide, et votre célérité ! =D>

les motifs de conception ne sont pas du pré mâché.
Ce sont des méthodes de conception, des démarches ou principe que l'on peu suivre afin d'avoir un code organisé et robuste.

on peu le faire sans cela, mais c'est une aide appréciable et éprouvée ;)

d'ailleurs en t'indiquant cela je pense que tu as une idée pour faire ce que tu voulais ?

@+

Ah d'accord, merci pour les explications. Les patterns c'est vrai, encore un truc à apprendre, mais c'est beaucoup moins fun et gratifiant que d'y arriver par la seule force du raisonnement :D

ce n'est pas possible.

un plugin c'est pattern [url=http://fr.wikipedia.org/wiki/Strat%C3%A9gie_(patron_de_conception)]Stratégie[/url] ([url=http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php/separer-ses-algorithmes-le-pattern-strategy]exemple en php[/url]).

Dans ce cas tu n'a pas de raison de forcer la visibilité d'une méthode (ou même d'autre chose en faite).
D'ailleurs tu n'as pas d’intérêt à forcer à connaitre le code d'un autre, c'est même un principe du développement : limiter l'adhérence entre les objets.

Avec le motif Stratégie tous ce qui t'intéresse c'est que la classe plugins implémente ton interface le reste c'est pas ton problème vu que tu ne va agir que sur les méthodes que tu connais.

tu peux aussi regarder le motif [url=http://fr.openclassrooms.com/informatique/cours/programmez-en-oriente-objet-en-php/laisser-une-classe-creant-les-objets-le-pattern-factory]factory[/url] (plus évolué que l'exemple) pour la gestion des plugins.
il y a surement moyen d'y caser une chaine de responsabilité a voir ;)


@+

@+

Ah d'accord, sisi mais ce que je cherche à faire c'est à forcer quelqu'un d'autre que moi à l'écrire comme ça. Si par exemple il hérite la classe parent mais oublie le protected sur la méthode il faudrait que ça lève une erreur... Là ce n'est pas le cas :?
(C'est pour un système de "plugins", c'est pour ça que quelqu'un qui n'a pas conçu le code au départ risque de faire l'erreur.)

class Fille extends Parent
{
protected function maMethode()
{
}
}

Euh c'est à dire ? Un bout de code pour illustrer ?

Tu peux pas la forcer directement dans le code ?

Bonjour,

Je cherche à forcer la visibilité d'une méthode de classe fille à être protected, j'utilise pour cela une classe parente abstraite mais le problème c'est que la classe fille peut très bien implémenter cette méthode avec une visibilité "public" sans que cela lève une erreur :[code]class Parent
{
abstract protected maMethode();
}
class Fille extends Parent
{
public function maMethode()
{
}
}[/code]
D'après la doc PHP c'est le comportement normal puisque la visibilité de la méthode de la classe fille doit être équivalente ou supérieure (protected ou public).
Mais alors comment faire pour forcer une méthode de classe fille à être dans la visibilité voulue et uniquement celle-ci (ici protected) ?

Désolé l'explication n'est peut-être pas claire mais donc pour résumer je veux absolument que la méthode maMethode() de la class Fille soit protected et qu'une erreur soit levée si ce n'est pas le cas...

Merci