Reprise du message précédent :
Ah ben voilà quelque chose qui m'a l'air pas mal

J'ai décidé de faire pareil : un FrontController général qui instancie le bon PageController... Voir plusieurs PageController dans le cas de vues composites

Normal c'est moi qui l'ai fait
 

Bon, question.
 
Mon machin actuel est une sorte de portail de services.
J'ai donc une appli principale (à la racine de mon serveur), dont le boulot est d'afficher une sorte de menu de services.
Puis j'ai un ensemble de services (sous /nomduservice/), qui ont besoin de certaines classes de l'appli principale, en leur ajoutant des méthodes.
 
Sachant que suivant le client je n'ai pas forcément tous les services d'activés, est-ce que vous mettriez plutot le code à ajouter directement dans la classe de l'appli principale, ou est-ce que vous créeriez (ce que je pense) une classe spécifique au service qui en dériverait?

un système de plugins, normalement, rien ne t'oblige à ajouter des méthodes à des classes existantes.

Une interface ou un protocole Service implémenté dans les différents services

 
...donc je dérive les classes existantes.
C'est bien ce que je pensais faire, m'enfin demander ne mange pas de pain.

(typiquement, j'ai la classe d'accès à la base de données, qui est dans ce cas...)

Ben je dirais que ça dépend quand meme du nombre de service...
perso, je sais que c'est assez brouillon, mais comme j'ai pas forcément bcp de classe, elle sont toutes défini (ainsi que mes fonctions) dans une seul page "fonctions.php", et les différent module font un include de cette seul et unique page...
 
mais c'est vrai que niveau structure, c'est quand meme un peu brouillon mon affaire  

non, justement, c'est ce que j'entendais par "ajouter des méthodes à une classe" il doit y avoir un autre moyen.  
 
créer des "brèches" ("extension point" comme on dit chez les zulu de RDC), ces brèches sont caractérisées par des interfaces. Tes services implémentent ces interfaces et viennent les enregistrer dans ces brèches.

c'est flou mais j'ai pas de détails non plus sur ton appli

 
Actuellement, 5...mais en constante augmentation.
 
Dans la version actuelle ya réinvention de la roue dans chaque (), pour des raisons de  reprise de vieux code et pas le temps de faire mieux, mais là je profite d'avoir un peu de temps pour tout refaire proprement...j'ai refait l'appli principale (avec ajout d'une compatibilité avec les anciens services), et je commence à m'attaquer aux services...
 
...en fait le problème d'avoir une grosse classe c'est surtout de parser systématiquement un gros paquets de fonctions dont on a de bonnes chances de jamais se servir...

 

Objectivement je vois pas trop comment je pourrais faire ça, là...
Je crois que vais me contenter de dériver mes classes dans chaque service, ce sera relativement propre, et simple à faire...
 
En fait je crois que je me suis mal exprimé...mon appli "menu" ne fait qu'afficher le menu, derrière les services sont indépendants (modulo la présence des variables de session créées par l'appli "menu" )...

 
Hello!
 
Je planche actuellement sur un MVC et je suis tombé sur ce thread.
 
Pour ton problème, je te conseillerais de te tourner vers les Patterns Decorator ou Strategy. Ca t'éviteras de devoir dériver tes classes à outrance tout en ajoutant de nouveaux comportements.
 
- - - - - - - - - - - - -
 
J'expose mon concept MVC à vos commentaires :
J'ai un FrontControler qui balance tout ce qui est statique dans le cas contraire, il delegue à un ApplicationControler (Decorator).
 
Mon Model (Composite) intégre un DAO et des ordres d'execution (Command). Le DAO s'occupe de tout les accès données (BDD, HTTPRequest, Files system, Files Remote, Bundles, etc...). Il est lié au Controler par Observer.
 
Un Datas Application est utilisé par le Model pour toutes les données de l'API.
 
Mon View (Composite) est lié au DatasApplication par Observer. La représentation est effectuée par Strategy.
 
Les évenements AppCtrl sont gérés par State. State met en place ses Models et Views par scripting. State execute les commandes du Model et la composition de la View.
 
Actuellement, le DAO n'est pas encore stable (dans le concept). Il aura bien un DatasTransfert, un factory pour les connecteurs, mais pour les requetes je cherche vers un Mediator.

loto !

  Kamoulox

Ah, toi aussi...

ayé, j'ai retrouvé le mot que je cherchais : FOUTAISES !!!

J'en ai quand même profité pour regarder vite fait Decorator...et je vois pas du tout l'intérêt, en fait!

moi non plus, j'ai jamais utilisé sciement. ça me saoule dans tout ce qui est wrapping de forwarder les messages.

Ca sert juste à pas faire d'héritages quand on pige pas comment ça marche

ouais c'est bien ce que je dis...c'est un pattern pour les gens qui font du C, ça...

Nan, c'est aussi pour faire des concours de bite avec les collègues
 
Exemple:

Argumentes STP
Merci

C'est une manière simple et élégante pour rajouter des propriétés à une classe à la volée. De plus, on peut les combiner, et ça avec l'héritage, c'est pas possible, il faut créer autant de classes suplémentaires qui offriraient toutes les combinaisons (Bonjour la maintenance!).
Ca permet aussi de proposer plusieurs résultats d'un même objet sans se trimbaler autant d'objets qu'on a de vues (redondance, mémoire).
Ca soulage la classe des propriétés optionnelles.
 
Maintenant, je ne connais pas précisément ton besoin, mais pour ajouter des propriétés à un objet, Strategy ou Decorator sont cool.

Mwouai... J'utilise pas du pattern pour utiliser du pattern, mais bien parce que ça répond à un problème.  
 
Les patterns ne sont pas du code. Le code peut être une implémentation d'un pattern.
Depuis quand MVC est du code ?
Est-ce qu'un Singleton est inutile et non-fonctionnel ? Ca va dépendre à quoi tu le destine. Combien d'implémentation d'un Singleton peux tu entrevoir ? Language, codeur...
 
Quand tu cherches une solution à un problème, tu fais peut-être du pattern sans le savoir. Les patterns sont déjà une solution, c'est quand même domage de perdre son temps à en chercher une autre.
 
Y'a-t-il un Mediator dans l'assemblée pour que Monsieur comprenne ? Un Interpreter ?
 
Les patterns ne sont pas des révolutions, mais des solutions. D'ailleurs, la majorité des patterns viennent de Smalltalk, c'est pour dire si c'est une révolution...
 
Tu vois pas leurs utilités ? Possible et normal, moi aussi j'ai mis le temps et d'ailleurs je ne les maitrise pas tous encore. Mais une fois que t'en tiens un, tu peux plus t'en passer et t'en cherches un autre et encore... Merde alors, d'un coup y'a moins de problème !
 
KiK0o

Mais oui bien sûr
C'est sûrement pour ça que tu te sens obligé de préciser à chaque fois quel pattern tu implémentes, comme si on en avait quoi que ce soit à foutre

et alors?

et alors?

depuis que 90% des des utilisations des singletons sont stupides  

Captain obvious to the rescue, t'en as d'autres des comme ça

C'est quoi le titre de ce thread ? "MVC...Architecture..." ! Ca te saute pas à la gueule que MVC est un pattern ? Ca t'étouffes que les patterns soient utilisés en architecture logiciel ? Et bien changes de thread vieux ! Ta contribution à ce thread risque d'être NullObject.
 

GLORI ALLELUIA !!! This guy is the chosen one !
T'es jamais tombé sur le besoin d'une unique instance ?
 
Et STP, une dernière fois : ARGUMENTE.

Un p'tit coucou. Ch'uis en plein dans mon framework, je viendrais poster des choses dès que c'est plus avancé

les 2 denières fois, c'était pour "chaine vide" et "null", donc bon, ça pête pas 3 pattes à un canard ...

lol
Bah c'est déjà ça. Si tu as repéré que pour ces objets une instance unique te suffisait en te garantissant l'intégrité de ses membres.
Perso, les classes systèmes, requete http, configuration client web, d'accès bdd sont des singletons. Une instance pour tout le monde !

Figure 1 : n'a pas compris le singleton.

Argumente STP!

Singleton c'est quand la valeur est intrinsèquement unique. Là c'est juste une économie de mémoire qu'il fait.

je crois que tu as loupé quelquechose

 
Un pattern c'est une solution à un problème. Alors si son problème c'est de l'optimisation je vois pas en quoi c'est mal d'utiliser Singleton

Outre l'économie mémoire, il y a aussi l'économie d'execution à l'instanciation. La valeur unique, c'est l'objet lui-même.
 
Système : Pourquoi forcer mes clients à tester n fois le système sur lequel ils sont lancées et à mettre en place les bonnes méthodes ?
HTTP request : même chose, mon appli ne répond qu'à une requette à la fois, pourquoi l'analyser n fois ?
Client web : Idem, un seul client web à la fois. Une fois les présentations faites, pourquoi les lui re-demander n fois.
BDD : Itou (Même avec 30 seveurs derrière, avec ou sans persistance de connection)
 
La structure d'un Singleton c'est déjà une économie de mémoire et de construction. Et ca permet d'être homogène. De plus, on peut répercuter des modifications éventuelles à l'ensemble des clients très rapidement, un "super objet" (Pas de clonage SVP). Conclusion pour toutes relations [serveur]1-n[clients], le Singleton a le mérite d'exister.

avoir besoin d'une seule instance ca n'a rien a voir avec un singleton tu peux partager l'instance entre tes objets sans avoir de singleton c'est plus simple et plus propre