Discussion :

[berceker united]

Oui ils sont dans un dossier "class".

Le problème je ne sais pas ou mettre cette fonction alors ... puisque aucun fichier serra tout le temps appelé sauf les classes ...

Donc si t'es fichier classe sont dans une repertoire classe t'a pas besoin de xxx*.class.php . Je dis ça, c'est pas grave c'est qu'un détail. Mais, lorsqu'on commence à raisonner ainsi, nous optimisons notre logique de développement sur d'autre détails qui paraissent au départ minime mais cumulé ça pete des flammes .


Pour l'autoload, tu le places dans un fichier qui sera appelé sur tes pages principale. Genre : index.php

[iwf-fr]

Ok c'est fait

Mais j'ai une question par exemple je fais un livre d'or ... le mieu c'est quoi de tout réunir dans une class livredor (Ajout,Lister les messages ... etc) ou de faire une class pour lister les mesages, une class pour l'ajout... ?

merci

[berceker united]

Ok c'est fait

Mais j'ai une question par exemple je fais un livre d'or ... le mieu c'est quoi de tout réunir dans une class livredor (Ajout,Lister les messages ... etc) ou de faire une class pour lister les mesages, une class pour l'ajout... ?

merci

En fait, c'est une question de point de vue. Personnellement, une classe ne peut s'ajouter elle-même dans une base de données, supprimer ou selectioner. C'est une autre classe.
Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
class groupe{
  public function AddUser(){}
  public function DelUser(){}
  public function getUser(){} 
 
}

C'est un gros résumé j'ai pas tous placé mais c'est pour expliqué qu'il y a bien souvent un classe qui controle une autre. Dans le cas ou c'est externe alors j'utilise une classe contrôleur. Si j'ai besoin d'ajouter un user hors d'un groupe spécifique alors il y aura un ctrlUser qui lui aura la methode AddUser.
De mon coté c'est un poil plus compliqué parce qu'en faite. La methode AddUser qui se trouve dans la classe ctrlUser et AdUser qui se trouve dans la classe Groupe appelle en faite la même methode mais avec des parametre different. Cette methode provient d'une classe DataUser qui lui est la seul à communique directement avec une source de données.
Mais je répète, c'est une conception personnel mais qui à passé de sacré épreuve de force.

[iwf-fr]

Ok en faite c'est plus question d'organisation...

Par exemple je fais un site d'actualité, j'ai besoin de lister les dernieres news, les news les plus vues, les news d'une catégorie, les dossiers ... etc

Le mieux c'est que je face une classe liste ou je met dedans mes fonctions pour lister les dernières news, les plus vues, les news d'une catégories, les dossiers ...

Ou une class news par exemple et dedans je met les fonctions pour lister les dernières news, les plus vues mais aussi pour ajouter une news ... etc

???????

En faite je suis un peu perdu sur l'organisation ...

[berceker united]

Ok en faite c'est plus question d'organisation...

Par exemple je fais un site d'actualité, j'ai besoin de lister les dernieres news, les news les plus vues, les news d'une catégorie, les dossiers ... etc

Le mieux c'est que je face une classe liste ou je met dedans mes fonctions pour lister les dernières news, les plus vues, les news d'une catégories, les dossiers ...

Ou une class news par exemple et dedans je met les fonctions pour lister les dernières news, les plus vues mais aussi pour ajouter une news ... etc

???????

En faite je suis un peu perdu sur l'organisation ...

Je dirais plutôt la premiere solution. Une classe qui possède toute les methodes permettant de lister des éléments.

[iwf-fr]

Ok comme ceci alors :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class Liste
{
     public function derniere_news()
     public function news_plus_vue()
     public function news_categorie($id)
     public function dossier()
     .... etc
}

[fenkys]

Personnellement je travaille en C++ depuis 12 ans et j'ai une bonne habitude de l'objet. Pour moi PHP5 a été une grosse avancée, le code de mon site est en pleine refonte pour passer à l'objet.

L'avantage de l'objet est qu'il oblige à reflechir à un plus haut niveau d'abstraction, à ce demander ce qui fait bien partie de l'objet et ce qui n'en fait par partie, quelle part du comportement d'un objet peut changer selon les circonstance et quelle part est commune. En bref, ça oblige à plus de reflexion et au final le résultat est plus propre. (J'en vois certains qui paniquent autour de moi. N'ayez pas peur, en objet on peut aussi sauter la phase de reflexion et coder comme un goret).

Pour ce qui est du typage fort je ne suis pas d'accord avec certains. Le typage faible de PHP apporte une souplesse absente des typages forts. C'est moins sécurisant et ça oblige à bien faire attention à ce que l'on fait si on ne veut pas aller dans le mur, mais changer cet aspect de PHP restraindrait beaucoup ses possibilités. Je rappelle qu'à la base je suis développeur C++ et donc le typage fort, avec ses avantages et ses inconvénients, je connais.

[berceker united]

Personnellement je travaille en C++ depuis 12 ans et j'ai une bonne habitude de l'objet. Pour moi PHP5 a été une grosse avancée, le code de mon site est en pleine refonte pour passer à l'objet.

L'avantage de l'objet est qu'il oblige à reflechir à un plus haut niveau d'abstraction, à ce demander ce qui fait bien partie de l'objet et ce qui n'en fait par partie, quelle part du comportement d'un objet peut changer selon les circonstance et quelle part est commune. En bref, ça oblige à plus de reflexion et au final le résultat est plus propre. (J'en vois certains qui paniquent autour de moi. N'ayez pas peur, en objet on peut aussi sauter la phase de reflexion et coder comme un goret).

Pour ce qui est du typage fort je ne suis pas d'accord avec certains. Le typage faible de PHP apporte une souplesse absente des typages forts. C'est moins sécurisant et ça oblige à bien faire attention à ce que l'on fait si on ne veut pas aller dans le mur, mais changer cet aspect de PHP restraindrait beaucoup ses possibilités. Je rappelle qu'à la base je suis développeur C++ et donc le typage fort, avec ses avantages et ses inconvénients, je connais.

Je pense comme toi que le type faible est une stratégie voulu. Elle permet un peut plus de rigueur. Après, le typage fort se fait de manière implicite c'est à dire que c'est au développeur qui fait que sont programme est propre et pas le language. S'il souhaite codé comme un "chien malade" il peut le faire avec n'importe qu'elle language.

[iwf-fr]

Moi en faite j'ai plus l'habitude de coder sans objet ... la c'est ma première !
Et j'ai du mal pour l'organisation ... pour que mon code soit claire pour d'autre développeur !

De plus je ne vois pas trop à quoi sert l'interface ?

[berceker united]

Moi en faite j'ai plus l'habitude de coder sans objet ... la c'est ma première !
Et j'ai du mal pour l'organisation ... pour que mon code soit claire pour d'autre développeur !

De plus je ne vois pas trop à quoi sert l'interface ?

Bizarre ça ma fait la même chose. Dernierement, j'ai dis que je ferais pas d'objet pour que ça soit developpé rapide et simple à maintenir.
En fait, j'ai pa pu m'en empêcher.
Je crois que c'est cuit pour moi

[iwf-fr]

Moi depuis que j'ai fais ma première classe ... j'adore ... la j'utilise la POO + Template pour un de mes sites, je comptais pas utiliser de POO mais ça me donne envie

[iwf-fr]

En réfléchissant pour la structure du site en POO ... je me remet en question sur l'organisation du code !

En faite berceker united tu m'avait dit la première solution soit un truc comme ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class Liste
{
     public function derniere_news()
     public function news_populaire()
     public function news_categorie($id)
     public function dossier
     ....
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class Ajout
{
     public function AddNews()
     public function AddDossier()
     public function AddUser()
}

Mais je me demande si ce serrait pas mieux un truc comme ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class News
{
     public function AjoutNews()
     public function ModifierNews()
     public function SupprimerNews()
     public function derniere_news()
     public function news_populaire()
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class Membre
{
     public function AddUser()
     public function UpdateUser()
     public function DeleteUser()
     public function ProfilUser()
}

En faite j'aimerais faire mon code POO très clair ... car ça ce pourrait que d'autre développeur passe sur ce code ! (c'est pour un projet PRO)

Merci

[berceker united]

En réfléchissant pour la structure du site en POO ... je me remet en question sur l'organisation du code !

En faite berceker united tu m'avait dit la première solution soit un truc comme ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class Liste
{
     public function derniere_news()
     public function news_populaire()
     public function news_categorie($id)
     public function dossier
     ....
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
class Ajout
{
     public function AddNews()
     public function AddDossier()
     public function AddUser()
}

Mais je me demande si ce serrait pas mieux un truc comme ça par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class News
{
     public function AjoutNews()
     public function ModifierNews()
     public function SupprimerNews()
     public function derniere_news()
     public function news_populaire()
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
class Membre
{
     public function AddUser()
     public function UpdateUser()
     public function DeleteUser()
     public function ProfilUser()
}

En faite j'aimerais faire mon code POO très clair ... car ça ce pourrait que d'autre développeur passe sur ce code ! (c'est pour un projet PRO)

Merci

Ha non je crois que tu as du mal comprendre ou je t`ais mal compris.
Tu peux avoir une classe qui te permet d`avoir une liste de méthode qui retourne une liste d`élement.

Pour les classes que tu proposes c`est une question de point de vue. Personnellement j`estime quùne classe ne fait pas le travail d`enregistrement des ses attributs. Donc une classe New ne peut pas s`autoajouter dans une base. Comme je le disais c`est un des points de vue de l`objet.

[iwf-fr]

Ok mais dans de cas comment fait-tu ?

Tu as pas un exemple de projet ? (ou je pourrais voir comment c'est fait par un pro)

[berceker united]

J'ai pas d'exemple lisible car mon projet est présent sur plus de niveau donc

Je dis pas que ce que tu as montré n'est pas bon, hein. C'est que j'ai une logique un peut différente.

Pour résumé j'ai 3 groupes de classe.
controleur, Data et Metier.
Metier represente les classes qui represente en gros ton projet.
Data est une librairie de classe qui permet de communiquer avec une source de données (base de données). Elles (les classes qui la compose) sont chargé de faire le lien entre le metier et la base de données.
Controleur une sorte de chef d'orchestre.
Exemple

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
Class ctrlMembre{
   public function AddUser(parametres){
      $objdataMembre = new dataMembre();
 
      $objMembre = new Membre();
      $objMembre->setAccesseur /*Liste d'accesseur*/
      $objdatMembre->AddUser($objMembre);
   }
}
 
Class dataMembre(){
 
  public function AddUser(Membre $objMembre){
      /*requête sql renseigné par l'objet membre*/
  }
}

Grosso merdo voila comment je me débrouille. Pourquoi ?
- Je m'assure que les données des membres vont toujours passé par la classe Membre ainsi.
- Qu'une seul voit d'entré pour la source de donnés.
- Les requête sont tous placé au même endroit.

[iwf-fr]

Ok c'est différent de ma logique ...

Moi pour je ferais plus de ce style ou je gère tout pour les news :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class News
{
     public function AddNews()
     public function UpdateNews()
     public function RemoveNews()
     public function LastNews()
     public function ListNews($id)
}

Après par exemple dans mon fichier je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$news = new News();
$news->AddNews();
 
$Smarty->Assign('message','La news à bien été ajouté');

Tout ce que je cherche, c'est que ce soit très clair et simple ...

[Wharenn]

Grosso merdo voila comment je me débrouille. Pourquoi ?
- Je m'assure que les données des membres vont toujours passé par la classe Membre ainsi.
- Qu'une seul voit d'entré pour la source de donnés.
- Les requête sont tous placé au même endroit.

Excellent !
Je suis également en pleine réflexion sur la réorganisation de mon code en Objet et j'étais un peu gêné par le fait d'autoriser une classe élément à s'automanipuler dans la base. Ta solution me plait bien je sens que je vais l'adopter

C'est en effet super de passer avant par la classe élément pour pouvoir s'assurer que les données sont bien présentes et sont dans le bon format !

Merci bien !

De plus je ne vois pas trop à quoi sert l'interface ?

L'interface est très utile avec l'héritage pour obliger les classes filles à redéfinir certaines méthodes dans leur implémentation.

[gtraxx]

Il faut bien avouer que la POO est super pratique et qu'en plus la propreté du code est indiscutable par rapport a la procédural.
Mais ce n'est pas pour une question de propreté que la POO est fort apprécié, c'est pour la puissance de l'utilisation dans des projets a grande échelle.
Cependant l'utilisation des class n'est pas des plus facile dans certain cas si on y mets pas du sien ou que les explications ne sont guère claire .
Par exemple j'ai un peux de mal a comprendre :

• class interface (exemple pas claire)
• class abstract (exemple absent)
• class reflexion (sa sert a quoi exactement)
• je crois que c'est tout lol

Pour le reste pas de problème, ce qui n'arrête pas mon envie de connaître les 3 qui me font défaut et qui doivent être pratique dans bien des cas en production qui je dirai même se feront désirer rapidement.

[berceker united]

Il faut bien avouer que la POO est super pratique et qu'en plus la propreté du code est indiscutable par rapport a la procédural.
Mais ce n'est pas pour une question de propreté que la POO est fort apprécié, c'est pour la puissance de l'utilisation dans des projets a grande échelle.
Cependant l'utilisation des class n'est pas des plus facile dans certain cas si on y mets pas du sien ou que les explications ne sont guère claire .
Par exemple j'ai un peux de mal a comprendre :

• class interface (exemple pas claire)
• class abstract (exemple absent)
• class reflexion (sa sert a quoi exactement)
• je crois que c'est tout lol

Pour le reste pas de problème, ce qui n'arrête pas mon envie de connaître les 3 qui me font défaut et qui doivent être pratique dans bien des cas en production qui je dirai même se feront désirer rapidement.

Une interface est une sorte de classe "Charte de bonne conduite". En terme technique elle ne sert à rien. Elle a aucune action réelle dans une application. Elle ne sert seulement à aider le developpeur.
Je vais prendre l'exemple d'un assembleur de PC. Tous les assembleurs du monde se sont réunie et ont décidé qu'un pc doit contenir au moin
- Une carte mere avec ces caractéristiques ...
- Une carte graphique avec ces caractéristiques ...
- Un lecteur optique avec ces caractéristique ...

Ils se sont serrés la main et chacun part de son coté avec cette charte. A l'usine, si jamais il y a un pc qui ne possède ces éléments, il est rejeté car le plan de base qu'il a accepté ne correspond pas.

Une interface c'est un peut prêt la même chose. C'est une classe ou tu lui donnes les plans de base. Si ta classe qui utilise cette interface ne colle pas avec, elle est rejeter.
Je pouvais prendre un exemple plus simple . C'est comme si tu dessinais à partir d'un calque.
Si tu supprimes toute les interfaces de ton application il y aura aucune différence de fonctionnement sur l'application. Comme je le disais, elle ne sert qu'a aider le developpeur.
Une classe Abstraite.
C'est une classe Maman. Elle possède les méthodes commune à toute les classes qui vont dériver d'elle. Par contre, il est hors de question de se taper la mère seulement ses filles . Ce que je veux dire c'est qu'il n'est pas possible de l'instancier.
Une classe abstraite qui ne possède pas de classe dérivé ne sert à rien.

Maintenant en utilisant les deux en même temps, que peux t'il arriver ?

Tu as une classe Fille qui hérite de la classe Maman qui est une classe abstraite. Dans cette classe abstraite il intègre une interface.
Ben la classe fille va devoir se conformer à cette interface. Manque de chance pour elle, il est obligatoire d'intégrer la methode suivante :

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
<?
interface CharteDeBonneConduite
{
    public function FermeTaBoucheEtVaFaireLaVaisselle();
 
}
 
 
class Maman implements CharteDeBonneConduite{
}
class Fille extend Maman{
    public function FermeTaBoucheEtVaFaireLaVaisselle(){
   }
}
?>

Ben ouai, Maman veut faire respecter une charte de qualité pour ses filles
Chose à savoir. Si jamais dans Maman j'intégrais FermeTaBoucheEtVaFaireLaVaisselle(). C'est elle qui va faire la vaisselle, donc les filles n'ont pas besoin de le faire. Elle est maline cette maman

[gtraxx]

Donc si je comprend bien une class abstract membre par exemple pourrai contenir les fonction de base qui serai étendue dans une class dérivé et le seul moyen d'instancier serai par l'intermédiaire de notre fille.
Les interfaces sont plus ou moins pareille a l'exception que celle-ci doit avoir des fonctions qui colle.
Par contre je ne savais pas que le mots réservé implement étais utilisé pour définir les class fille.
Je vois le truc mais vaguement pour l'instant , je doit me faire quelque exemple pour me l'enfoncer dans le crâne.