POO : Conseils choix d'objet Fermé

Question

Bonjour tout le monde,  

Je m'en remet à vous pour avoir des avis, conseils, orientations sur la conception de classe en PHP. 

Le principe du système c'est de la gestion de données, en gros je met en bdd un très grand nombre de valeurs issues d'installations de production chaque jour :  
pour une date t j'ai x valeur_numériques (production, température,tension,voltage...).  
J'ai énormément de fonction de vérification des données (pas d'envois, date erronée, mauvais échelle des données, et moult merveilles ...). 

Ces données sont utilisées dans des graphiques qui rendent compte de l'état des installations. 

Le système a déjà une taille importante sans objet, du coup j'ai un peu de mal à l'imaginer. 

J'ai déjà fait quelques classes : Utilisateur, Connexion, Medias sans soucis, elles sont un peu à part. 
(1/ Première petite question : j'ai vu plusieurs cas où pour une classe Utilisateur, il y avait une seconde classe UtilisateurAdmin avec les méthodes, ex: vérification de login, compter utilisateur, modification, etc , ce qui fait que dans la classe Utilisateur il n'y aucune méthode. Cela a-t-il une réelle utilité?) 

Mon problème est en rapport avec la classe Installations, elle possède un certain nombre de paramètres basiques (id,nom...) , comme je l'ai dis il y a beaucoup de calcul sur les date et les valeurs_numériques issues des installations.  

2/ Faut il créer des classes Date{} et Données{ //(Contenant les différents types de données) } à mettre dans la classe Installations, pour pouvoir instancier une donnée numérique à une date t pour telle installation, ou bien uniquement des tableaux dans lesquels je mets un peu ce que je veux? 

3/ Est-il utile de créer une classe Graphique{} pour leur construction?  

Idées, conseil, avis, même sur des choses que je n'aurai pas précisé je suis preneur ! 

Merci d'avance à ceux qui prendront le temps de répondre.

Bionik · Answer

Salut,

Je vais tenter de répondre à ta première question. 

Déjà ne confonds-tu pas classe et objets? Si ton système est géré par plusieurs utilisateurs de nivaux différents (différents droits), tu peux créer une classe générique qui sera Abstraite et qui s'appellera Utilisateur par exemple. Dans cette classe tu mettras aussi des méthodes génériques comme se loguer (enfin, ça dépend de ton système aussi). 

Il faut savoir qu'une classe abstraite ne peut pas être instanciée, elle a pour rôle d'être héritée, comme ça toutes les classes filles pourront redéfinir les méthodes de la super classe (la classe mère) et/ou en ajouter.

Tu stockes aussi beaucoup de données tu dis, je te conseilles de faire toutes les vérifications nécessaires pour conserver l'intégrité de tes variables. Ça, ça se fait avec les mutateurs ou setters et tu récupères les valeurs avec les accesseurs ou getters. C'est le principe même de l'encapsulation.

Rappelles-toi de ceci: une classe, une entité. Tu dois d'abord repérer toutes tes entités et ensuite créer leur classe puis faire toutes les manipulations nécessaires.

Bonne chance.

Utilisateur anonyme · Answer

Merci de la réponse,

Tu as raison j'ai complétement mélangé les termes classe et objet dans mon texte, ça va pas ce matin :s ! J'ai modifier je crois que ça devrait être plus compréhensible maintenant.
C'est vrai que j'ai du mal à identifier clairement les entités!!

Tu m'amènes une nouvelle question, pourquoi utiliser plutôt une classe abstraite et pas une interface?
En fait j'ai vu plusieurs manières de faire mais je ne comprend pas vraiment les différences concrètes de tel ou tel cas.

J'ai l'impression que je tend à me retrouver avec une unique classe Installation qui sera gigantesque, et ça me plait pas vraiment! 

Bon ap'

Bionik · Answer

La seule différence entre une interface et une classe abstraite c'est que cette dernière en plus des méthodes peut avoir des attributs comme toute classe normale, par exemple tu pourrais avoir login et motDePasse comme attributs dans la classe Utilisateur, donc lorsque les autres classes hériteront de la classe Utilisateur ils auront d'office comme propriétés ce que t'avais défini dans la classe mère (Utilisateur).

Ça va t'éviter de créer une interface à implémenter dans des classes et que ces dernières se retrouvent toujours avec les propriétés qu'ils auront toujours en commun (login et motDePasse).

Une classe, une entité. Avec ta classe Installation, tu vas vite te perdre! Or le but même de la POO c'est plus de clarté dans le code, la ré-utilisabilité, l'extensibilité, la facilité de mise-à-jour etc... Es-tu sûr que ton application va répondre à toutes ces questions?

Utilisateur anonyme · Answer

Ok merci pour toutes ces précisions, c'est super!!

Ben pour l'instant mon appli répond pas à grand chose, je me rends compte que cette classe toute seule n'est pas une bonne idée, je n'ai pas encore eu l'illumination  mais j'y travail.

POO : Conseils choix d'objet

4 réponses

Discussions similaires