Modèles de conception non-POO? [fermé]

70

J'ai seulement entendu parler de "modèle de conception" utilisé pour le code orienté objet, et les modèles GoF n'incluent que les modèles de conception POO, mais les modèles de conception sont des solutions élégantes pour les problèmes de programmation courants, n'est-ce pas? Il n'y a rien dans cela qui dit qu'ils doivent être limités à la POO, n'est-ce pas?

J'aimerais voir quelques exemples de modèles de conception en dehors du domaine de la programmation orientée objet. Avez-vous des? Existe-t-il une telle réalité (aucun livre, comme le livre de GoF, ne doit nécessairement avoir été écrit, il convient simplement de l'utiliser, c'est suffisant)?

Ils peuvent être spécifiques à certains langages de programmation, mais les modèles généraux (au niveau du paradigme) sont préférés, autres que ceux orientés objet.

design-patterns Anto
la source
8
Je pense que le principal inconvénient des livres de modèles de conception populaires a été de créer une foule de personnes qui pensaient que ces modèles ne s’appliquaient qu’aux langages orientés objet. Les modèles de création sont discutables, mais à peu près tous les autres peuvent et sont implémentés dans des langages sans objet orientant tout le temps. Je suis sûr que cet effet secondaire n'était pas l'intention de l'auteur, c'est néanmoins un effet secondaire.
Pemdas
14
Eh bien, les objets sont un modèle de conception dans les langues non-OO :)
back2dos
1
Pire encore, les manuels de modèles ont créé toute une classe de personnes qui estiment que tout problème doit être résolu en appliquant un modèle spécifique (généralement le dernier qui leur a été enseigné par un enseignant qui croit lui-même).
jwenting

Réponses:

25

Jetez un coup d'œil à la série Linux Kernel Design Patterns. Les articles sont en relation avec un langage non orienté objet (C) et je crois qu’ils sont bien écrits:

Sakis
la source
Ils utilisent cependant une approche orientée objet.
Kais
12

En fait, c’est un paradoxe: l’un des modèles les plus populaires de non-OO est ... "Classe".

Parce que OO a été inventé dans des langages non-OO, les développeurs ont dû le simuler (et ils le font même maintenant), de sorte que le modèle est né. LISP et C en sont des exemples.

Mais suivez mon conseil: ne commettez pas d'erreur commune - n'utilisez pas de modèles uniquement parce que c'est cool , vous avez besoin de raisons sérieuses pour justifier l'utilisation de modèles (au moins ceux d'origine).

Prenez le modèle de commande par exemple - bien que ce soit agréable et qu'il sépare l'appelant du destinataire, il ne devrait pas être utilisé sauf si vous en avez réellement besoin - car les opérations doivent être exprimées à l'aide de verbes - ce qui signifie méthodes. Et en utilisant toutes les commandes, vous vous retrouveriez avec un groupe de lambda OO complètement décentralisés -> il en serait de même pour beaucoup de stratégies.

Kamil Tomšík
la source
11

"Modèle de conception" est en réalité un euphémisme pour "solution de contournement". Les modèles de conception ont été inventés pour contourner les lacunes et les défauts des langages OO . Par exemple, prenons le modèle itérateur qui a finalement conduit à l’introduction des collections en Java. Groovy s'est débarrassé de beaucoup plus de modèles en les convertissant en fonctionnalités de langage: vous n'avez plus besoin du modèle décorateur, car vous pouvez ajouter des méthodes aux classes existantes dans Groovy.

Cela signifie que vous pouvez trouver des modèles de conception partout. En fait, chaque "meilleure pratique" peut être considérée comme une forme simple de modèle de conception.

Aaron Digulla
la source
9
D'accord! De Paul Graham : "Par exemple, dans le monde OO, on entend beaucoup parler de" patterns ". [...] Quand je vois des patterns dans mes programmes, je considère cela comme un signe de problème. La forme d'un programme devrait refléter Toute autre régularité dans le code est un signe, du moins pour moi, que j’utilise des abstractions qui ne sont pas assez puissantes - souvent que je génère à la main l’expansion d’une macro que j'ai besoin d'écrire. "
Andres F.
7
Je ne suis pas d'accord avec un modèle de conception étant une solution de contournement. Les deux sont opposés. Une solution de contournement est un correctif à court terme mis en place pour contourner un obstacle spécifique. Les modèles de conception sont des solutions réutilisables à long terme. L'objectif du motif de décorateur est d'ajouter fonctionnellement «sans» modifier la classe. Vous pouvez placer différents décorateurs sur un objet sans que l'objet le sache.
Despertar
La raison pour laquelle les motifs sont considérés comme une "solution de contournement" est que la décoration d'un objet doit être une caractéristique du langage. Au lieu de cela, nous devons écrire beaucoup, beaucoup de lignes de code pour implémenter ceci. Par exemple, le modèle d'itérateur est devenu partie intégrante de nombreux langages modernes. Pour les langages OO plus anciens, vous devez effectuer quelques simulations pour les simuler.
Aaron Digulla
@AaronDigulla Je ne vois pas pourquoi vous pensez qu'un motif comme celui du décorateur est une implémentation aussi lourde; vous parlez de quelques lignes de code. Une classe contient une autre classe et lui transmet les requêtes avec quelques fonctionnalités ajoutées. Il utilise l'héritage et la composition de manière à rendre l'appel d'un objet décoré équivalent à l'appel de l'objet lui-même. Je considère cette transparence comme une force. Cela vous permet d'échanger des décorateurs au moment de l'exécution. Lorsque vous dites que groovy n’a pas besoin de décorateur, car il peut ajouter des méthodes À une classe, il semble que vous manquiez l’essentiel.
Despertar
2
Le modèle Iterator n'a pas été remplacé par une nouvelle fonctionnalité de langue dans les langues modernes. Il vient juste avec une implémentation par défaut pour les collections communes. Ce n’est pas parce qu’il a une implémentation par défaut que le modèle n’est pas utilisé. Si vous écrivez votre propre collection, vous devrez la mettre en œuvre vous-même.
Despertar
10

LtU mentionne que Jeremy Gibbons est en train d'écrire un livre sur les modèles de programmation fonctionnelle. Jetez un œil à quelques-uns des blogs de M. Gibbon, Patterns in Functional Programming . Notez qu'il recommande de lire ses messages du plus ancien au plus récent.

Son article intitulé Modèles de conception en tant que programmes génériques d'ordre de données d'ordre supérieur (pdf) modélise de manière fonctionnelle le modèle de Gang of Four: Composite, Itérateur, Visiteur et Constructeur. Il décrit les modèles de programmation avec des équations récursives dans la programmation en origami (plis et dépliés).

Corbin March
la source
7

Au lieu de nommer des modèles de design non-oo, j'aimerais vous donner quelques exemples de livres comportant de nombreux modèles (certains d'entre eux seront toujours spécifiques à OO):

J'espère que cela t'aides

KeesDijk
la source
Ce sont ceux que je recommanderais également, ainsi que les modèles d'intégration d'entreprise de Hohpe & Woolf .
TMN
Les modèles de Fowler sont très OO :)
David Conde Le
@David Conde :) La plupart d'entre eux sont purement OO, ils sont tous écrits de manière OO, mais certains s'appliquent également aux non OO: regardez "Modèles de présentation Web", "Modèles d'état de session", "Modèles de distribution "
KeesDijk le
2

Dans la programmation fonctionnelle (en particulier Haskell), il existe de nombreux modèles et idiomes qui ne correspondent pas très bien à la POO. Les types fantômes sont un exemple bien connu, et vous pouvez en trouver beaucoup plus sur la page wiki haskell sur Idioms .

yatima2975
la source
1

La programmation modulaire est très populaire dans les bibliothèques numériques et les applications lourdes en mathématiques (les logiciels numériques sont notoirement difficiles à modéliser à l'aide des modèles orientés objet, principalement parce qu'il y a très peu de choses à encapsuler).

quant_dev
la source
Utilisé dans JS & "pure C": en.wikipedia.org/wiki/Module_pattern
umlcat
0

J'aime penser aux strucutres de données telles que les files d'attente, les listes liées, les arbres, les graphiques, etc. en tant que modèles. Ils définissent certains modèles pour stocker des données et les traiter. Ils peuvent sembler primitifs par rapport aux modèles plus haut de gamme de Gang of Four, mais ce sont néanmoins des modèles. Je veux dire, que se passerait-il si quelqu'un implémentait une pile en tant que FIFO au lieu d'un LIFO et inversement pour une file d'attente et les nommait autrement?

DPD
la source