Discussion :

[daddiz]

Bonjour,

Je me lance dans la POO. J'ai déjà de bonnes notions mais j'avoue que j'ai du mal à comprendre la logique d'élaboration d'une classe ainsi que des possibilités raccordées à d'autres classes.

Pouvez vous m'expliquer 2 ou 3 points sur des exemples concrets. J'ai lu dans des bouquins tout ce qui concerne la syntaxe mais leur classe expérimentale avec des voitures ne me parle pas vraiment.

Je souhaiterais élaborer une classe d'authentification par exemple.
1- Comment réfléchit-on aux différents attributs et méthodes de la classe Authentification ? (lesquels choisir en gros)
2- Quel chemin élaborer dans sa petite cervelle pour mener à bien la classe ?

Je sais pas si c'est bien clair mais je vous remercie pour toute l'aide éventuelle que vous pourriez m'apporter

[daajack]

Le principe de la POO c'est de concevoir son application comme un ensemble d'objets qui vont interagir entre eux.
Il y'a des objets évidents comme des voitures ou des utilisateurs et d'autre moins, comme un contrôleur de modèle MVC qui représente un concept virtuel, chargé de rediriger l'utilisateur sur les "sous-objets" en effectuant des traitements récurrents à chaque appel de page.
Puis il y'a aussi les "extend" ou héritage de classe, qui permettent de créer des classes de base desquels dériveront d'autres classes plus complexes.

Une erreur que l'on voit souvent, ce sont des gens qui créer des classes, desquelles ils instancient un objet, puis appellent les méthodes indépendamment, de la même manière qu'ils appelleraient des fonctions. Une sorte de groupement de fonctions. Hors la force des objets, à mon avis, est qu'ils ont une "vie" et évoluent dans le déroulement du script en leur affectant différentes valeurs de propriétés qui affecteront les appels futurs des méthodes.

C'est là que l'on voit les limites du PHP en tant que langage "non-persistant". A chaque nouvel appel de page, l'ensemble des objets sont réinitialisés et il faut les reconstruire. Il faut donc aborder l'utilisation des objets en PHP de manière différentes que dans d'autres langages "persistants" (ex. Java, JS). Les objets sont là pour donner au développeur un canevas, qui l'obligera à structurer son application, sans lui donner l'évolutivité de la POO. Les objets sont crées, puis évolué lors de la création de la page sans intervention de l'utilisateur, si ce n'est les arguments et variables de sessions récupérés.

On dit que la programmation objet va à l'encontre du mode de réflexion classique que nous utilisons, il faut donc "réapprendre à penser", de manière objet.

Je sais c'est très théorique, c'est un essai, et je reste ouvert à toute critique.

Pour reprendre ton exemple, voilà comment je m'y prendrai :

Déjà créons une classe Utilisateur, la base.
Il faudra y mettre les propriétés propres à l'utilisateur, qui seront utiles pour la suite des opérations. Le nom, la catégorie, l'heure de connexion, l'ip etc...
Viennent les méthodes, déjà login() et logout(), changeCategory() for example
Pour chaque page/action tu peux créer une classe qui contiendra comme propriété notamment la catégorie requise, ainsi qu'une méthode grantAccess() qui autorisera (ou pas) l'accès à l'utilisateur. Cette objet sera appelé par le contrôleur.

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
21
class Controler {
 
}
 
class Utilisateur {
  var nom;
  var role;
  var ip;
  var timeLogin;
 
  function __construct() {}
  function login() {}
  function logout() {}
  function changeRole() {}
}
 
class Action {
  var access;
 
  function checkAccess() {}
}

Après il y'a des classes de mapping de DB (ORM) qui transforment en objets les tables, et qui vont donc te permettre de gérer tes types de données avec des objets. Ainsi l'ajout d'un objets se fera en 2 étapes, d'abord en passant dans la méthode addVoiture de ton objet Action (récupération et contrôle des données), puis add() de ton objet Voiture (insertion dans la DB).

Cette exemple démontre qu'il est important de structurer ton app avant d'écrire ta première ligne de code. Puisque tu devras définir qui gérera quoi, en évitant de donner les mêmes rôles à plusieurs classes, et le mot d'ordre reste le même que pour n'importe quel paradigme, éviter à tout prix la redondance et optimiser les modifications futures.

Voili, j'espère avoir été clair... et pas trop chiant aussi

[mon_nom_est_personne]

pour savoir que je doit mettre dans une classe d'abord faut definir a quel moment dans ton programme cette classe va intervenir. et pour ca y'a pas 36 solutions, la modelisation. perso je suis assez old school je fait encore ca en ordinogramme.
par exemple ou se place une classe qui gere des authentification ?
normalement le fleau de ton appli sera :
- j'arrive dessus
- j'arrive sur la page d'authentification
- verifie que j'existe dans la db
- si oui me permettre d'accedé au reste sinon rentre chez toi.

Donc deja le truc cool tu sais que ta classe va se trouver entre un formulaire et une page.
donc p-e si tu as une classe d'analyse de form, pensé a un prototype de type form_listener pour dire que tout roule comme dans du beure avec d'autre form.

ensuite qu'est-ce qui va se passer dans cette classe
- tu va verifier si la personne est deja logé ou pas
si non :
- tu recup login/pwd
- tu verifie qu'une personne avec de tels attributs exit en db
- si oui, par example tu cree une session sinon tu retourne faux.

si oui :
- retourne vrai

sous cette forme c'est pas tres visible mais dans un diagramme tu vois les boite dobc tu compte et tu as t'es methode plus ou moins.

une pour verifier si une personne est deja logé
une verrifier un login et un pwd
et comme les deux sont pas lier ou on pas de constant pas d'attribut.

[daajack]

+1 pour mon_nom_est_personne

Déjà son logo est trop cool, vive GITS.
Et modéliser son app. est chaudement recommandé, p.ex. avec l'UML

[daddiz]

Merci à vous deux pour vos explications

C'est quand même pas mal chaud de situer l'affaire !!!
Mais grace à vos prouesses j'ai quand même cerner quelques trucs... Auriez vous une idée d'une appli simple que je pourrais réaliser en tenant compte de vos conseils mais en essayant d'utiliser le maximum d'éléments (héritage, interface, abstraction, etc...) ?
Et vous montrer mon boulot au fur et à mesure de son évolution (de la modélisation à la prog) pour que vous me corrigiez ?

Encore merci pour votre aide et soutien...

[daajack]

Par définition, une application simple nécessitera un minimum de techniques différentes.
Ce n'est donc pas une bonne idée de vouloir utiliser le plus d'éléments possibles. Il vaut mieux réfléchir, à partir de ton application, aux éléments dont tu auras besoin et c'est l'usage que tu feras des ces méthodes qui t'aideront à comprendre leur rôle.

Tu peux essayer de faire un système de gestion d'accès comme tu proposais pour commencer et nous poster le code quand tu auras un peu avancé, on te donnera notre avis... en tout cas j'essaierai