Une collection de modèles de conception et d'idiomes en Python.
N'oubliez pas que chaque modèle comporte ses propres compromis. Et vous devez prêter davantage attention à la raison pour laquelle vous choisissez un certain modèle qu'à la manière de le mettre en œuvre.
Modèles de création :
Modèle | Description |
---|---|
usine_abstraite | utiliser une fonction générique avec des usines spécifiques |
borg | un singleton avec un état partagé entre les instances |
constructeur | au lieu d'utiliser plusieurs constructeurs, l'objet constructeur reçoit des paramètres et renvoie les objets construits |
usine | déléguer une fonction/méthode spécialisée pour créer des instances |
évaluation_paresseuse | modèle de propriété évalué paresseusement en Python |
piscine | préinstancier et maintenir un groupe d'instances du même type |
prototype | utiliser une usine et des clones d'un prototype pour de nouvelles instances (si l'instanciation coûte cher) |
Modèles structurels :
Modèle | Description |
---|---|
3 niveaux | données<->logique métier<->séparation de présentation (relations strictes) |
adaptateur | adapter une interface à une autre à l'aide d'une liste blanche |
pont | un intermédiaire client-prestataire pour adoucir les changements d'interface |
composite | permet aux clients de traiter les objets individuels et les compositions de manière uniforme |
décorateur | envelopper la fonctionnalité avec d'autres fonctionnalités afin d'affecter les sorties |
façade | utiliser une classe comme API pour plusieurs autres |
poids mouche | réutiliser de manière transparente les instances existantes d'objets avec un état similaire/identique |
contrôleur_frontal | requêtes à gestionnaire unique arrivant dans l'application |
mvc | model<->view<->controller (relations non strictes) |
procuration | un objet canalise les opérations vers autre chose |
Modèles comportementaux :
Modèle | Description |
---|---|
chaîne_de_responsabilité | appliquer une chaîne de gestionnaires successifs pour essayer de traiter les données |
catalogue | les méthodes générales appelleront différentes méthodes spécialisées en fonction du paramètre de construction |
méthode_de_chaînage | continuer le rappel de la méthode objet suivante |
commande | regrouper une commande et des arguments à appeler plus tard |
itérateur | parcourir un conteneur et accéder aux éléments du conteneur |
itérateur (alt. impl.) | parcourir un conteneur et accéder aux éléments du conteneur |
médiateur | un objet qui sait comment connecter d'autres objets et agir comme un proxy |
mémento | générer un jeton opaque qui peut être utilisé pour revenir à un état précédent |
observateur | fournir un rappel pour la notification des événements/modifications des données |
publier_abonnement | une source syndique les événements/données à plus de 0 auditeurs enregistrés |
enregistrement | garder une trace de toutes les sous-classes d'une classe donnée |
spécification | les règles métier peuvent être recombinées en enchaînant les règles métier à l'aide d'une logique booléenne |
État | la logique est organisée en un nombre discret d'états potentiels et l'état suivant qui peut être transitionné vers |
stratégie | opérations sélectionnables sur les mêmes données |
modèle | un objet impose une structure mais prend des composants enfichables |
visiteur | invoquer un rappel pour tous les éléments d'une collection |
Conception de modèles de testabilité :
Modèle | Description |
---|---|
dépendance_injection | 3 variantes d'injection de dépendances |
Modèles fondamentaux :
Modèle | Description |
---|---|
motif_délégation | un objet gère une requête en déléguant à un deuxième objet (le délégué) |
Autres :
Modèle | Description |
---|---|
tableau noir | modèle architectural, assembler différentes connaissances de sous-systèmes pour construire une solution, approche IA - modèle sans groupe de quatre |
graph_search | algorithmes graphiques - modèle sans groupe de quatre |
hsm | machine à états hiérarchique - modèle sans groupe de quatre |
Modèles de conception en Python par Peter Ullrich
Sebastian Buczyński - Pourquoi n'avez-vous pas besoin de modèles de conception en Python ?
Vous n'avez pas besoin de ça !
Bibliothèques enfichables via des modèles de conception
Lorsqu’une implémentation est ajoutée ou modifiée, veuillez consulter les directives suivantes :
Ajoutez une description au niveau du module sous la forme d'une docstring avec des liens vers les références correspondantes ou d'autres informations utiles.
Ajoutez la section "Exemples dans l'écosystème Python" si vous en connaissez. Il montre comment des modèles pourraient être appliqués à des problèmes du monde réel.
façade.py a un bon exemple de description détaillée, mais parfois la plus courte comme dans template.py suffirait.
Pour voir les versions compatibles Python 2 de certains modèles, veuillez consulter la balise héritée.
Lorsque tout le reste est terminé, mettez à jour la partie correspondante du README.
Veuillez exécuter ce qui suit avant de soumettre un correctif
black .
Cela peluche votre code.Alors soit :
tox
ou tox -e ci37
Ceci exécute des tests unitaires. voir tox.ini pour plus de détails../lint.sh
Ce script peluchera et testera votre code. Ce script reflète les actions du pipeline CI. Vous pouvez également exécuter les commandes flake8
ou pytest
manuellement. Des exemples peuvent être trouvés dans tox.ini
.
Vous pouvez trier les problèmes et les demandes d'extraction qui peuvent inclure la reproduction de rapports de bogues ou la demande d'informations vitales, telles que des numéros de version ou des instructions de reproduction. Si vous souhaitez commencer à trier les problèmes, un moyen simple de commencer consiste à vous abonner aux modèles Python sur CodeTriage.
Les gens de Mutable.ai ont créé un assistant d'IA compatible avec la base de code. Essayez-le