JeuWeb - Crée ton jeu par navigateur

Version complète : POO cheat sheet
Vous consultez actuellement la version basse qualité d’un document. Voir la version complète avec le bon formatage.
Hi guys,

en révisant symfony, je suis tombé sur des cheat sheet : des anti seches rappelant les principales fonctions sur un sujet de ce ( très complet ) framework.

d'où une idée :
et si on faisait une POO PHP cheat sheet ?

ça rappellerait :
_ la syntaxe de base de la POO
_ l'héritage
_ les interfaces & classes abstraites
_ sérialization / dé-sérialization
_ de bonnes pratiques de conception

le tout en une seule page, d'un seul coté. comme ça on peut l'imprimer et l'avoir sous la main quand on veut coder.

ça vous dit ?

A+

Pascal
Ça serait très pratique en tout cas !

Petite question.
Quand tu dis " les interfaces & classes abstraites ", que veux-tu dire exactement ?
Les interfaces et les classes abstraites sont des composants important de la POO.
Voici un lien qui explique la différence entre les deux.

Il existe pas mal de cheat sheet, pour le php aussi. J'en ai pas trouvé spécifique à la poo en revanche... Donc bonne idée.
Le truc c'est que la POO c'est d'avantage des concepts à comprendre que des difficultés technique à mettre en place, donc je sais pas trop ce qu'il faudrait y mettre dans cette fiche recapitulative Smile
De mon côté, je ne n'ai encore vue tourner d'interfaces en action (ou sans m'en rendre compte, comme ça semble être le cas avec les exceptions) sur une application telle qu'un jeu par navigateur. Ça semble être intéressant sur le papier mais j'aimerai beaucoup les voir à l'œuvre.

Si quelqu'un peut me dire pour quoi je pourrais les utiliser, je suis partant. Wink


Sephi-Chan
Sephi-Chan a écrit :Ça semble être intéressant sur le papier mais j'aimerai beaucoup les voir à l'œuvre.
Sephi-Chan


Le meilleur exemple est de regarder les composants de Zend Framework
apres tu peux regarder aussi sur Fragento et aussi magento

je suis comme toi sur ce point en théorie je comprend le principe mais en pratique :heuuu: . peut-être au moment de la construction de l'objet ? peut-être plus rapide ?
Les interfaces sont très très puissantes quand elles sont fournies par l'API du langage et profondément intégrées. Par exemple en PHP5 il y a l'interface ArrayIterator : il suffit d'implémenter cette interface, et les instances de notre classe seront "parcourables" avec foreach Smile
C'est surtout pour ce genre de "magie" que les interfaces deviennent puissantes. Sinon il faut savoir qu'on ne peut hériter que d'une classe à la fois, mais on peut implémenter plusieurs interfaces, donc ce n'est pas le même concept. En gros une interface c'est le fichier .h de PHP Wink

Mais c'est comme tout dans l'objet, l'idée principale c'est d'ajouter énormément de contraintes. Les interfaces sont purement dans cette optique : ajout de contrainte, et uniquement de contrainte. On ne gagne pas de fonctionnalités (à part en utilisant les interfaces magiques du langage), mais on s'ajoute des contraintes. L'idée est donc d'avoir un système permettant de baliser de manière efficace le terrain, ni plus ni moins.
Sephi-Chan a écrit :De mon côté, je ne n'ai encore vue tourner d'interfaces en action (ou sans m'en rendre compte, comme ça semble être le cas avec les exceptions) sur une application telle qu'un jeu par navigateur. Ça semble être intéressant sur le papier mais j'aimerai beaucoup les voir à l'œuvre.

Si quelqu'un peut me dire pour quoi je pourrais les utiliser, je suis partant. Wink

Sephi-Chan

allez, un exemple d'utilisation : le design pattern strategy

c'est utilisé avec une interface : une famille d'algorithme implémente une interface, ce qui rend ces algorithmes interchangeables dans le code.

ça peut servir par exemple pour définir des familles de "métier", chaque métier possède une classe précise, mais correspondant à l'interface :
_ travailler()
_ fatiguer()
_ boire()

le script général reste le même, mais s'appuie sur une classe "métier" particulière, par exemple :
_ étudiant => boire() de la bière
_ informaticien => boire() du café
_ cheminot => etc

A+

Pascal, qui va écrire