POO vs programmation fonctionnelle vs procédurale [fermé]

Quelles sont les différences entre ces paradigmes de programmation et sont-ils mieux adaptés à des problèmes particuliers ou des cas d'utilisation favorisent-ils les uns les autres?

Exemples d'architecture appréciés!

Ils sont tous bons à leur manière - Ce sont simplement des approches différentes des mêmes problèmes.

Dans un style purement procédural, les données ont tendance à être fortement découplées des fonctions qui les opèrent.

Dans un style orienté objet, les données ont tendance à emporter avec elles une collection de fonctions.

Dans un style fonctionnel, les données et les fonctions ont tendance à avoir plus en commun les unes avec les autres (comme dans Lisp et Scheme) tout en offrant plus de flexibilité en termes d'utilisation des fonctions. Les algorithmes ont également tendance à être définis en termes de récursivité et de composition plutôt qu'en boucles et en itération.

Bien sûr, la langue elle-même n'influence que le style préféré. Même dans un langage purement fonctionnel comme Haskell, vous pouvez écrire dans un style procédural (bien que cela soit fortement déconseillé), et même dans un langage procédural comme C, vous pouvez programmer dans un style orienté objet (comme dans GTK + et API EFL).

Pour être clair, «l'avantage» de chaque paradigme réside simplement dans la modélisation de vos algorithmes et structures de données. Si, par exemple, votre algorithme implique des listes et des arbres, un algorithme fonctionnel peut être le plus judicieux. Ou, si, par exemple, vos données sont très structurées, il peut être plus judicieux de les composer comme des objets si tel est le paradigme natif de votre langue - ou, elles pourraient tout aussi bien être écrites comme une abstraction fonctionnelle de monades, ce qui est le paradigme natif de langues comme Haskell ou ML.

Le choix de celui que vous utilisez est simplement ce qui a le plus de sens pour votre projet et les abstractions que votre langage prend en charge.

Je pense que les bibliothèques, outils, exemples et communautés disponibles l'emportent complètement sur le paradigme de nos jours. Par exemple, ML (ou autre) pourrait être le langage de programmation polyvalent ultime mais si vous ne pouvez pas obtenir de bonnes bibliothèques pour ce que vous faites, vous êtes foutu.

Par exemple, si vous créez un jeu vidéo, il y a d'autres bons exemples de code et SDK en C ++, donc vous êtes probablement mieux avec ça. Pour une petite application Web, il existe d'excellents cadres Python, PHP et Ruby qui vous permettront de démarrer et de fonctionner très rapidement. Java est un excellent choix pour les grands projets en raison de la vérification à la compilation et des bibliothèques et plates-formes d'entreprise.

Auparavant, les bibliothèques standard pour les différents langages étaient assez petites et facilement répliquées - C, C ++, Assembler, ML, LISP, etc. comme les communications réseau, le chiffrement, les graphiques, les formats de fichiers de données (y compris XML), même les structures de données de base comme les arbres équilibrés et les tables de hachage ont été omises!

Les langages modernes comme Python, PHP, Ruby et Java sont désormais livrés avec une bibliothèque standard beaucoup plus décente et ont de nombreuses bonnes bibliothèques tierces que vous pouvez facilement utiliser, grâce en grande partie à leur adoption d'espaces de noms pour empêcher les bibliothèques d'entrer en collision les unes avec les autres, et garbage collection pour standardiser les schémas de gestion de la mémoire des bibliothèques.

Ces paradigmes ne doivent pas être mutuellement exclusifs. Si vous regardez python, il prend en charge les fonctions et les classes, mais en même temps, tout est un objet, y compris les fonctions. Vous pouvez mélanger et faire correspondre le style fonctionnel / oop / procédural en un seul morceau de code.

Ce que je veux dire, c'est que dans les langages fonctionnels (du moins dans Haskell, le seul que j'ai étudié), il n'y a pas de déclarations! les fonctions ne sont autorisées qu'une seule expression à l'intérieur !! MAIS, les fonctions sont des citoyens de première classe, vous pouvez les transmettre en tant que paramètres, avec un tas d'autres capacités. Ils peuvent faire des choses puissantes avec peu de lignes de code.

Dans un langage procédural comme C, la seule façon de transmettre des fonctions est d'utiliser des pointeurs de fonction, et cela ne permet pas à lui seul de nombreuses tâches puissantes.

En python, une fonction est un citoyen de première classe, mais elle peut contenir un nombre arbitraire d'instructions. Vous pouvez donc avoir une fonction qui contient du code procédural, mais vous pouvez la faire circuler tout comme les langages fonctionnels.

Il en va de même pour la POO. Un langage comme Java ne vous permet pas d'écrire des procédures / fonctions en dehors d'une classe. La seule façon de passer une fonction est de l'envelopper dans un objet qui implémente cette fonction, puis de le passer.

En Python, vous n'avez pas cette restriction.

Pour l'interface graphique, je dirais que le paradigme orienté objet est très bien adapté. La fenêtre est un objet, les zones de texte sont des objets et le bouton OK en est un également. D'un autre côté, des choses comme le traitement des chaînes peuvent être effectuées avec beaucoup moins de frais généraux et donc plus simples avec un paradigme procédural simple.

Je ne pense pas que ce soit une question de langue non plus. Vous pouvez écrire des informations fonctionnelles, procédurales ou orientées objet dans presque tous les langages populaires, bien que cela puisse être un effort supplémentaire dans certains.

Pour répondre à votre question, nous avons besoin de deux éléments:

1. Compréhension des caractéristiques des différents styles / modèles d'architecture.
2. Compréhension des caractéristiques des différents paradigmes de programmation.

Une liste des styles / modèles d'architecture logicielle est présentée dans l' article sur l' architecture logicielle sur Wikipeida. Et vous pouvez les rechercher facilement sur le Web.

En bref et général, la procédure est bonne pour un modèle qui suit une procédure, la POO est bonne pour la conception et la fonctionnalité est bonne pour la programmation de haut niveau.

Je pense que vous devriez essayer de lire l'histoire de chaque paradigme et voir pourquoi les gens le créent et vous pouvez les comprendre facilement.

Après les avoir compris, vous pouvez lier les éléments des styles / modèles d'architecture aux paradigmes de programmation.

Je pense qu'ils ne sont souvent pas «contre», mais vous pouvez les combiner. Je pense aussi que souvent, les mots que vous mentionnez ne sont que des mots à la mode. Il y a peu de gens qui savent réellement ce que signifie "orienté objet", même s'ils en sont les évangélistes les plus féroces.

Un de mes amis écrit une application graphique en utilisant NVIDIA CUDA . L'application s'intègre très bien avec le paradigme OOP et le problème peut être décomposé en modules de manière ordonnée. Cependant, pour utiliser CUDA, vous devez utiliser C, qui ne prend pas en charge l' héritage . Par conséquent, vous devez être intelligent.

a) Vous concevez un système intelligent qui imitera l'héritage dans une certaine mesure. Ça peut être fait!

i) Vous pouvez utiliser un système de hook , qui attend de chaque enfant C du parent P qu'il ait un certain remplacement pour la fonction F. Vous pouvez demander aux enfants d'enregistrer leurs remplacements, qui seront stockés et appelés en cas de besoin.

ii) Vous pouvez utiliser struct fonction d' alignement de la mémoire pour convertir les enfants en parents.

Cela peut être soigné, mais il n'est pas facile de trouver une solution fiable et pérenne. Vous passerez beaucoup de temps à concevoir le système et rien ne garantit que vous ne rencontrerez pas de problèmes à mi-chemin du projet. Exécution en de l'héritage multiple est encore plus difficile, voire presque impossible.

b) Vous pouvez utiliser une politique de dénomination cohérente et utiliser l' approche diviser pour régner pour créer un programme. Il n'aura aucun héritage mais comme vos fonctions sont petites, faciles à comprendre et formatées de manière cohérente, vous n'en avez pas besoin. La quantité de code que vous devez écrire augmente, il est très difficile de rester concentré et de ne pas succomber à des solutions faciles (hacks). Cependant, cette méthode de codage ninja est la méthode de codage C. Rester en équilibre entre la liberté de bas niveau et l'écriture d'un bon code. Un bon moyen d'y parvenir est d'écrire des prototypes en utilisant un langage fonctionnel. Par exemple, Haskell est extrêmement bon pour les algorithmes de prototypage.

J'ai tendance à m'approcher b. J'ai écrit une solution possible en utilisant l'approche a, et je vais être honnête, cela ne semblait pas naturel d'utiliser ce code.