Bonsoir,
 
je debute en PHP Objet, après avoir longtemps programmé en procédural. Ca va c'est cool  
Mais je coince à un moment particulier.
 
En fait, je n'arrive toujours pas à comprendre le sens, la signification, l'interet d'un attribut ou d'une méthode statique.
 
Ok selon la definition, un attribut statique est accessible sans avoir besoin d'instancier une classe.  
Mais alors, une méthode statique ? accessible sans avoir besoin d'instancier aussi ?
 
ça veut dire qu'on peut les appeler uniquement avec Maclasse::attribut, ou Maclasse::function() ? Si c'est le cas, je comprends pas, j'y arrive tout aussi bien sans "static".
 
Et apparemment pour appliquer le modèle Singleton en PHP5, il suffit juste d'appliquer un "static" à une méthode.
 
J'ai vraiment du mal à me situer. Je suis en train de pondre une classe de connexion à Mysql via PDO, en partant d'un modele Singleton/Factory, c'est pour ça que j'aimerai bien mieux comprendre.
 
Le pb c'est que j'ai lu les 100aines de cours et de tutoriaux à ce sujet, j'arrive toujours pas à percuter.
 
Est ce que quelqu'un aurait le lien ultime pour enfin comprendre et me coucher avec l'illumination du siècle et sans cette impression d'inachevé, ou simplement m'expliquer avec des exemples "pour un nul", sans static/avec static, etc...
 
Merci d'avance.  et dsl si c'est censé être le B-ABA de la programmation, mais pourtant je developpe depuis 6 ans, et j'ai jamais pu comprendre le principe.

Oui, une méthode et un attribut normaux font partie de l'instance de la classe, alors qu'une méthode ou un attribut statique font partie de la classe même et sont donc partagés entre les instances

En général, sans "static" il faut passer par une instance. Après PHP étant complètement con ça ne m'étonnerait pas qu'on puisse faire autrement, il faudra demander aux spécialiste de ce truc.

C'est une implémentation possible d'un singleton.
 
Mais il ne faut pas utiliser de singletons, c'est pas une bonne idée, le singleton ça pue 99% du temps.

Merci pour ta réponse.

D'accord.
Mais dans tous les cas, lorsqu'on instancie une classe, cette instance porte les attributs declarés. qu'ils soient statique ou non.. ?

Ok pour les attributs statiques, effectivement dans l'exemple je ne peux pas accéder à $attribut via Classe::$attribut, si je ne l'ai pas declaré en statique. De même que la méthode Attribut() ne pourra pas modifier l'attribut (fatal error dans les 2 cas)

Par contre, pour la méthode Affichepoin(), je peux l'appeler via Classe::Affichepoin() , static ou non, d'où mon interrogation.

En fait, il me faudrait un exemple simple et trivial sur une application d'une méthode statique (et d'un attribut tant qu'à faire)

Bon, j'ai trouvé un excellent article
 
http://classes.scriptsphp.org/arti [...] on-en-PHP5
 
C'etait tres simple et très clair.
 
Par contre, je suis pas contre une précision sur pourquoi les méthodes non statiques sont aussi accessibles sans instanciation, et donc l'interet d'une methode statique.

Apparement t'as pas prêté attention la première fois donc je répète: il ne faut pas utiliser de singletons.

et pourquoi cela ?
 
un singleton de connexion mysql c'est tres bien, et bien plus propre que 90% de ce qui traine sur le web niveau conexion / requetes mysql
 
apres PDO ca doit etre meiux, mais j'ai pas vraiment touché a ca

 
il faut pas non plus être extrémiste à-dessus, ça reste un choix raisonnable pour certaines choses.

(en général j'en ai pour gérer la conf de mes applis, par exemple...)

• Parce qu'ils empêchent de comprendre les dépendances entre les composants (ils sont accessibles de partout directement, donc on ne peut pas savoir facilement quand un objet dépend de l'état du singleton)
• De ce fait, ils deviennent extrèmement difficiles à tester, et rendent tout composant dépendant du singleton intestable
• Parce qu'ils contiennent un état global mutable accessible de toute l'application
• Parce qu'ils sont extrèmement difficiles à étendre (sous-classer)
• Parce qu'un jour ou l'autre il t'en faudra plus d'un
• Parce qu'ils se foutent complètement du principe de responsabilité unique (une sous catégorie de la Separation of Concerns)

Je te propose les lectures suivantes:
http://steve.yegge.googlepages.com [...] red-stupid
http://www.codingwithoutcomments.c [...] g-me-down/
http://misko.hevery.com/2008/08/17 [...] cal-liars/
http://misko.hevery.com/2008/08/21 [...] tons-gone/
http://misko.hevery.com/2008/08/25 [...] ingletons/
http://tech.puredanger.com/2007/07 [...] singleton/

En quoi?

Le logging et certaines factories. C'est à peu près tout. Mais habituellement quand on en a vraiment besoin on le sait, et on se rend compte que le singleton est utile. Dans 99% des cas d'utilisation vus "au large", le singleton est une mauvaise idée.

Donc autant commencer par "dites non au singleton" et après on voit à relaxer cette règle, pas l'inverse (default deny toussa).

Donc je reste sur ma position: il ne faut pas utiliser de singletons

ok je voyais pas cela comme ca
 
je disais tres bien dans le sens, ou on fais une connexion par page à la bdd, pas x Connexions pour x requetes

Tu crées ta connection en début de page, et soit tu l'utilises comme globale de partout PHP style (ce qui est 100% équivalent à en faire un singleton, mais avec moins de bordel) soit tu la passes explicitement en paramètre à tous ceux qui en ont besoin (ce qui te permettra de savoir quand des composants n'ayant aucun besoin de le faire demandent une connection SQL)

 
Perso je considère l'option pour toute classe qui sert grosso modo de proxy vers une ressource unique et utilisée à plusieurs endroits. Donc oui, le logging, mais aussi la gestion de la conf, la factory qui me donne un objet d'accès à la db, celle qui me donne un objet qui va mettre à jour la vue...c'est envisageable d'en utiliser pour ces objets, même s'il ne faut pas tomber dans le piège d'en faire sytématiquement
 

 
je suis tout à fait d'accord sur le fait qu'il ne faut pas en abuser et y réfléchir calmement avant de se lancer, mais il ne faut pas non plus verser daans l'excès inverse.

C'est toujours envisageable, la question est de savoir si c'est utile, et si c'est plus intéressant que les alternatives (DI, injection classique, ...). La raison est habituellement non sur le long terme.

Ya pas d'excès inverse

si, déclarer unilatéralement qu'il ne faut pas utiliser de singleton quoi qu'il arrive

Non, c'est comme les meurtres, déclarer unilatéralement qu'il ne faut pas tuer les gens c'est pas un excès
 
Ben à chaque fois que tu utilises un singleton, dieu tue un chaton

 
Est-ce que tu détestes les chatons à ce point?

Plus sérieusement, lis les liens que j'ai fourni, ils expliquent la chose très bien, "il ne faut pas utiliser les singletons" est un bien meilleur défaut que l'inverse, comme je l'ai spécifié une fois que la personne sait un peu mieux coder elle découvrira d'elle même que de temps en temps, une fois tous les 6 mois un singleton peut être intéressant. C'est d'ailleurs la conclusion du Yegge

 
 
c'est un peu ce que je disais, c'est le mal si tu n'y réfléchis pas.

Pas mal le débat  
 
Bon, j'ai sur la même page 2 requêtes (un SELECT et un INSERT) à la BDD de part et d'autre.
 
sur le coup, un Singleton pour la connexion ça f'ra l'affaire non ?

ça ne veut rien dire, du point de vue objet, ta question. Rien de rien.

 
Bon... je crois que j'ai encore besoin de pratique pour cerner toutes les subtilités de l'objet.
 
Moi ce que je comprends, c'est que pour la premiere requête SELECT, je vais créer l'objet ConnexionBdd pour me connecter, puis plus loin dans la page pour la requête INSERT, je vais réinstancier mais ça sera la même instance ConnexionBdd qui sera utilisée, d'où l'interet d'un singleton.
V'la, dsl j'ai une approche assez simpliste de la progr

Quand tu dis "plus loin dans la page", ça veut dire que c'est le même script?
Si oui, quel intérêt de créer une nouvelle instance si tu en as déjà une à cet endroit?

A part le singleton et le comptage du nombre d'objets relatifs à une classe, je ne connais pas d'autre utilisations des attributs statiques.
 
Pour le débat pour ou contre singleton, je pense qu'il faut se poser la question du clonage de l'objet. Si on veut interdir le clonage (économie de ressources, etc...), il faut utiliser le singleton. Sinon non.
 
En fait c'est un peu comme ta femme...tu la prends qu'en t'en as besoin !  

 
Oui dans le même script, mais dans une autre methode de la classe.
 
Effectivement, je pensais qu'il fallait faire new PDO() avant chaque nouvelle méthode qui appelle l'objet de connexion.
 
Enfin bon, je m'emmêle trop les pinceaux  

Ok, donc pas une page, une classe.
Si tu as besoin de ton objet PDO à plusieurs endroits, ce serait peut-être une bonne idée de garder une référence dans cet objet...sinon effectivement une solution c'est d'avoir un singleton qui va te fournir l'instance déjà créée...bref, tu as plusieurs options, là...mais si tu veux pas de singleton ni recréer une nouvelle instance à chaque fois il va falloir soit passer ton objet PDO en paramètre de tes méthodes, soit le passer une fois et garder une référence dessus dans ton objet.