Bienvenue sur IndexError.

Ici vous pouvez poser des questions sur Python et le Framework Django.

Mais aussi sur les technos front comme React, Angular, Typescript et Javascript en général.

Consultez la FAQ pour améliorer vos chances d'avoir des réponses à vos questions.

design patterns : votre caisse à outils

+6 votes

je bidouille différents types de petit prog disparates, pour m'habituer à la POO, à l' itération, jouer avec la lib standard comme avec les GUI ou les framework...
Bref, j' explore et je saute sur toutes les mines, comme ça c'est fait.

J'ai l' intention de recycler mes trouvailles et de les affiner à mesure que j'avance dans mon apprentissage.
Cependant il va il y avoir un moment où ça deviendra toxique de continuer à trimbaler mes rustines, et comme on dit, ça sert à rien de réinventer la roue.
J'étais content quand j'ai découvert nullege, mais en fait compte c'est tellement abondant et en bloc que j'y vais seulement quand j'ai ciblé un module particulier.

Au final,y'a t il un top 10 du design pattern, chiant à pondre soi-même, mais génial à l'usage ?

demandé 7-Jun-2015 par buffalo974 (2,886 points)

Yép, mais je ne suis pas sûr de commencer à bosser dessus dans l'immédiat, j'ai un partiel à réviser là (tin les cours c'est chiant)

La meilleure contribution que vs puissiez faire, sera celle faite spontanément, qd vs serez disposé, disponible, de bne humeur. No stress, on a ts des trucs chiants (et prioritaires) a finir.

Je viens de tomber la dessus : https://python-3-patterns-idioms-test.readthedocs.org/en/latest/

Çà couvre certains des design patterns cités précédemment, appliqués en python.

@Nsukami_
Oki, faisons ça directement sur le dépôt, ça nous évitera de faire plusieurs fois le même taf

@boblinux, oui je vais d'abord finir de rapatrier des idées que j'avais dans une vieille version, et ensuite je le met dans le dépôt.

Y'aura besoin d'un gros coup de karcher, ce que tu vois actuellement c'est propre et c'est grâce à l'aide de dan qui a un niveau largement au-dessus du mien.

Ma version prototype était plus complète ( tableau de bord fiche personnage,armes, aliments, livres magiques, pièces d'or,monstres qui se baladent) mais carrément dégueulasse. Impossible à maintenir.

Entre temps mon niveau a augmenté, mais le fait d' écrire dessus m' aidera a encore m'améliorer. Ce serait marrant de partager une page de score des membres de la team
quand le jeu sera jouable.

2 Réponses

+4 votes

Juste histoire de prendre la question sous un autre angle, je m'autorise à passer de la caisse à outils à la bibliothèque, et carrément d'aller voir au fond sous la poussière.

  • L'ouvrage phare sur le sujet (Design Patterns) fait la liste de 23 patterns et propose des implémentation en C++.

  • On peut aussi trouver ceci : Design Patterns in Dynamic Languages. L'auteur se propose de revisiter ces 23 patterns dans la perspective des langages dynamiques (d'où le titre je pense...). Je vous donne juste sa conclusion :

    16 of 23 patterns are either invisible or simpler.

    A noter qu'il n'est jamais fait mention de python, mais que 90% de ce qu'on y trouve s'y applique très bien.

Voilà, vous savez quoi faire pour votre prochaine nuit d'insomnie...

PS: Sinon vous pouvez aussi jeter un oeil par là : 1, 2, 3, 4, 5.

répondu 8-Jun-2015 par bubulle (2,238 points)
+4 votes

Les patterns iterator, singleton et decorator sont déjà intégrés par défaut dans Python. Savoir les utiliser est déjà un bon début.

Le pattern observer est toujours utile quand on veut créer un système d'événement.

Le pattern adapter/façade est indispensable quand on veut travailler avec une lib qu'on a pas le droit de toucher mais qui n'accepte qu'une sorte d'API.

Après, le reste ne sont pas des patterns mais des bonnes pratiques :

  • délégation
  • composition
  • découplage
  • injection de dépendance
répondu 10-Jun-2015 par Sam (4,984 points)

On pourrait mettre du code source en commun dans le dépôt crée par boblinux,
en plus du design pattern.

J'ai par exemple ce projet en chantier que je dois reprendre début juillet que je mettrai dans le panier quand ce sera prêt.
https://github.com/dangillet/Pythoria

@Sam, si tu connais un framework d'injection de dépendance sérieux dans l’écosystème je suis interessé.
Il y a bien des choses qui existent mais je n'ai pas l'impression qu'il y ait quelque chose qui sorte du lot (ou alors solution custom a la mano ?)

singleton et decorator sont déjà intégrés par défaut dans Python

Par contre cette phrase peut prêter a confusion :) le decorator en python n'est pas une implémentation du pattern decorator (ce que Bruce Eckel décriras mieux que moi sur son post a propos des decorators python)

Le dépot faif/python-patterns cité dans les précédents commentaires lui aussi ne traite que du decorator au sens python, et ne fais pas la différence entre les deux.

Le mélange des deux concepts peut être vraiment déroutant pour un débutant (situation vécue :) )

Si, c'est une implémentation du pattern décorator, simplement c'est une implémentation fonctionnelle et non une implémentation objet. La forme change un peu, mais le résultat est le même : on enrobe un code dans un autre code pour lui donner des fonctionalités en plus. Le problème actuellement avec les DP c'est qu'on ne les présente que sous une forme POO, mais c'est comme apprendre un logiciel en mémorisant les boutons, si on ne touche pas la notion derrière, le jour où la notion change, on est confus.

Ok.

Je vais faire un aveu, je ne suis pas calé programation fonctionnelle.

J'aurais été plus précis en disant que ce qu'on appelle "decorator" en python n'est pas l'implémentation du pattern decorator dans un paradigme objet.

Ca ne change en rien le propos, la distinction entre les deux est importante.

mais c'est comme apprendre un logiciel en mémorisant les boutons

J'ai une excuse, j'étais jeune.

Pour pousser la drosophylie un peu plus loin je suis interessé par l'intégration du pattern singleton dans python que tu cites (hors boolean et None) et surtout, comment l'utiliser.

Les modules sont des singletons. On ne peut les importer qu'une fois, les autres fois on récupère la même instance de l'objet module. La conséquence est que si on veut qu'une de nos classes ait une instance unique toujours à disposition de tout le monde à l'import, il suffit de l'instancier dans un attribut d'un module.

@buffalo974

Hâte de reprendre ensemble ton projet =D (j'pense qu'en juillet j'aurai aussi un peu plus de temps, notamment une fois que mes exams seront dans la poche :p )
Du coup tu vas le déplacer dans les repôts de la team indexerrorcoders si j'ai bien compris ?

...