Bonjour à toutes et à tous,

Je réalise mon second stage dans la même entreprise qui à de lourdes contraintes (pas de framework OpenSource, etc.), l'année dernière j'ai réalisé un premier projet en me basant sur mon framework personnel. Depuis mon framework a été adopté par les ingénieurs du service informatique. Mon framework est très basique et hors-mit le MVC et un Singleton pour le SQL, les ACL et les sessions, la POO offerte par PHP 5.2.* se borne à être utilisé comme namespace. Cette année ma tâche est lourd (200 pages de spécifications), j'ai, grosso-modo, une gestion des stocks très spécifique, multi-service, multi-stockage, beaucoup d'aspect organisationnelle sont mis en jeu, des produits sont commandées et/ou produit, plusieurs millions de produits sont utilisés chaque mois. Le projet, à moyen terme, visera à remplacer la gestion globale de l'entreprise. Ainsi, pour permettre une propreté dans le code, un meilleur extensibilité, etc. J'ai décidé de faire plus intervenir la conception objet et éliminer les redondances. Le but final sera d'avoir un code concis, plus cohérent, une IHM uniforme etc. Je vais donc utilisé l'héritage de manière intensive (Singleton, Modele, Vue, Controleur), d'autres Design Pattern (Proxy, Fabrique, Décorateur). Le but sera d'avoir une classe descriptif (contenant un ensemble de décorateursà des objets manipulés que je donnerait à chacune de mes classes du MVC pour qu'elle soient interprétés puis que seules certaines actions soient redéfinies au besoin.

Mon soucis est que PHP ne permet ni l'héritage multiple ni les classes paramétriques.
Je pensais utiliser un Singleton et une fabrique pour n'avoir qu'une seule instance de chaque objet manipulé.

J'aimerais savoir ce que vous pensez de mon approche ? existe-t-il des solutions pour obtenir le résultat que j'attends ?

Pour vos réponses,
Par avance,
Merci

KISS...

et y'a trop de "singletons" dans ton paragraphe, ça me fait pleurer mon petit ami le smiley =>
je suis pas trop fan du singleton. C'est le goto de l'objet.

En gros: tout ça c'est bien, mais évite d'en faire trop.

Bonjour,

c'est l'un des rares que je maîtrise.
pour rajouter une chose à mon message, ce que je veux c'est que ce soit dynamique, pas que le code soit généré automatique, à la sf.

Pour vos réponses,
Par avance,
Merci

Perso, dans l'appli en cours, je fais quasi tout en statique. Avant, tout en singleton. Le temps m'amène toujours à la réflexion, et le statique chez moi est à priori vite mal employé. Il est vrai que ce que je concois n'a pas pour objet d'être réutilisé, et en soit, les objets peuvent vite être remplacés par des groupes de méthodes (une classe quoi ^^). Mais cela se rapproche plus à un dossier dans lequel on met des dossiers, qu'à un réel développement objet. D'autre part, je souffre de l'absence de namespace, et je pense à terme m'orienter vers la technique de Zend, qui est, si je ne m'abuse, d'utiliser le underscore comme séparateur de namespace/classe. C'est assez lourd, mais bon ... En terme d'objet, le Singleton me parait très approprié, car contrairement au statique, l'objet, bien qu'unique, a toute la vie d'un objet : constructeur, etc. Actuellement j'ai pas mal de classe avec une méthode init() que j'assimile à un constructeur mais statique. c'est en gros une méthode qui devrait être appelée par php lors de démarrage du script (en JAVA, il me semble que init() existe ...) ... Bref. Je réfléchis et l'idée serait peut-être la construction d'un "arbre" de type :

$template->menu->items ou plus précisément Core::getInstance()->template->menu->items (car malheureusement, une variable n'est pas disponible aux enfants), ou Registry::get('template')->menu->items. Je pense que ici, le premier est mieux.

D'ailleurs c'est toujours mieux, encore une fois pas dans mon cas, mais en général, d'avoir qqchose de type $Core->template car au fond ce n'est pas aux autres objets de s'inquiéter de qui est $template à partir du moment où on en connait les propriétés et méthodes. Je dis peut-être une bêtise, mais on pourrait avoir plusieurs classes de gestion de template et seul celui qui a la responsabilité de la gérer, est responsable de la choisir. Alors que actuellement, j'ai une classe Template, et tout le monde y accède de façon statique, parce que moi dans mon appli je sais que elle me convient, mais dans une autre appli, ça ne serait pas forcément intéressant. Je pense aussi que la méthode est mieux que l'utilisation du Registry, car on a une hierarchie définie, mais on pourrait imaginer que Template est quand même une grande fille ^^ représentant la VUE, et déterminer trois grands parents au lieu de 1 : Core (controlleur), Template (Vue) et Tables (Model). Si ce n'est qu'au final, le grand chef reste le controlleur puisque c'est lui qui démarre l'application, et que je n'ai aucune classe Tables puisque mes classe de table sont indépendantes. Là, pour elles, cela reste un grand mystère.

J'ai pensé aussi, car je développe pas mal en encaspsulation, à ne permettre que l'accessibilité aux propriétés d'un objet que si la propriété est un objet, et de ne permettre que la lecture seule. C'est quand même mieux que Core::getInstance()->getTemplate->getMenu->getItems

Pour bien faire, une propriété "parent" devrait aussi exister, bien qu'un fils n'est pas forcément censé savoir qui est son père, là, de toutes façons, il le sait ...

Pour les Namespace, je devrais avoir quelque chose comme

application_Core (Namespace application, classe Core)
application_template_Template, application_template_menu_item, application_template_menu_group etc

Bref, je trouve que l'on souffre souvent, en tant que développeur PHP, d'un manque réel de connaissances à ce sujet, et il est souvent nécessaire, personnellement, à mon évolution, d'aller voir les autres langages beaucoup plus objets, pour en apprendre davantage. Par contre, trop d'objet tue l'objet : un développement à usage unique ne devrait pas être aussi objet qu'un développement à réutilisation comme DOMDocument, pour lequel on est content que tout soit objet.

Pour ce qui est de Registry, je l'ai utilisé dans le début de refonte d'une application, il répond bien au problème de portabilité des variables (tout confondu) mais la méthodologie en elle-même reste à revoir. Bref, je me démerde très bien dans le développement d'une application, sans me vanter, mais de nombreux points sont totalement à apprendre.

Bonjour,

c'est l'un des rares que je maîtrise.
pour rajouter une chose à mon message, ce que je veux c'est que ce soit dynamique, pas que le code soit généré automatique, à la sf.

Pour vos réponses,
Par avance,
Merci

Je crois sans trop me tromper que le mot clé est MVC. Sans rentrer dans la théorie pure et le respect pure des diktats que l'on pourrait lier à ce terme, un exemple concret est celui que j'ai développé récemment : chaque page est une classe. L'objet est instancié, dans son constructeur, il fait ce qu'il a a faire (ajouter des menus, en enlever, déterminer son contenu, etc), et c'est après que ma classe Template déclenche "la concaténation des données" et l'envoi. Et encore, les données ne sont pas encore envoyés au navigateur (attention, là l'évolution de l'appli rend la méthodologie mauvaise à mon goût), la classe de gestion des erreurs ajoute éventuellement les erreurs ou messages dans la page (soit supprime la page pour une erreur définie comme fatale et affiche le message, soit insère le message à l'endroit où la classe Template l'a indiqué, soit à la fin par défaut). La classe ^^ quoi

D'ailleurs, on pourrait très bien développer à la "framework", par exemple le controlleur, la vue etc, et dans le fichier index.php (je dis ça comme ça) :

$control = new Controlleur ();
$page = $control->getPage(); // $page est typé Page
$template = new Template();
$template->show($page);

Ce qui fait une abstraction supplémentaire ... l'idée me plaît bien. Mais j'ai la sensation que ça revient à utiliser un framework ^^ car si derrière je développe un menu, avec des éléments item, group, etc ... quelle différence ?

Edit : Désolé de t'avoir pollué ton post, mais je souffre terriblement d'un excès de Photoshop et d'un manque de méthodologie dans mes cours Et c'est plus fort que moi, à chaque fois que je code, je me pose des questions, et ça gonfle en moi, et quand ça explose ... ça fait des lignes et des lignes de textes

Bonjour,

Merci de vos réponses.
Alors, pour commencer, l'idée est de refondre un framework personnel, je ne peut effectivement pas prendre de framework pour différentes raisons : je travail dans un établissement dont les règles de sécurité stipule l'usage d'un framework spécifique, voire inconnu, ou d'aucun, mon framework y est déjà employé, les besoins sont très spécifiques.
J'ai demandé à quelques personnes autour de moi et voici le résultat (ci-joint).
Grosso-modo ma classe Descripteurs (classe métier) contiendra un ensemble de Champs. Cette classe influencera les fonctions par défaut de mon MVC. J'ai deux soucis : nommé mon MVC et fournir une couche DAL.
Normalement ma DAL est un objet, je n'en vois pas l'intéret par rapport à un Singleton... pouvez-vous m'éclairer ?

Pour votre aide,
Par avance,
Merci