POO cheat sheet - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : POO cheat sheet (/showthread.php?tid=1599) |
POO cheat sheet - pascal - 03-04-2008 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 RE: POO cheat sheet - orditeck - 03-04-2008 Ça serait très pratique en tout cas ! Petite question. Quand tu dis " les interfaces & classes abstraites ", que veux-tu dire exactement ? RE: POO cheat sheet - Manest - 03-04-2008 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 RE: POO cheat sheet - Sephi-Chan - 03-04-2008 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. Sephi-Chan RE: POO cheat sheet - cliknet - 04-04-2008 Sephi-Chan a écrit :Ça semble être intéressant sur le papier mais j'aimerai beaucoup les voir à l'œuvre. 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 ? RE: POO cheat sheet - naholyr - 04-04-2008 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 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 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. RE: POO cheat sheet - pascal - 04-04-2008 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. 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 |