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 l'un par rapport aux autres?
Exemples d'Architecture appréciés!
7 réponses
Tous sont 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 y opèrent.
Dans un style orienté objet, les données ont tendance à porter 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 de comment les fonctions sont effectivement utilisés. Les algorithmes ont également tendance à être définis en termes de récursivité et de composition plutôt que de boucles et d'itération.
Bien sûr, la langue elle-même n'influence que le style préféré. Même dans un langage fonctionnel pur 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 les API GTK+ et EFL).
Pour être clair, le "l'avantage" de chaque paradigme est tout 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 hautement structurées, il peut être plus logique de les composer en tant qu'objets si c'est le paradigme natif de votre langue-ou, il pourrait tout aussi facilement être écrit comme une abstraction fonctionnelle de monades, qui est le paradigme natif des langages comme Haskell ou ML.
Le choix que vous utilisez est tout simplement ce qui a 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 la programmation polyvalente ultime language mais si vous ne pouvez pas obtenir de bonnes bibliothèques pour ce que vous faites, vous êtes foutu.
Par exemple, si vous faites un jeu vidéo, il y a plus de bons exemples de code et SDK en C++, donc vous êtes probablement mieux avec cela. Pour une petite application web, il y a quelques grands Python, PHP, et les frameworks Ruby qui vous permettront de démarrer très rapidement. Java est un excellent choix pour les grands projets en raison de la vérification de la compilation et des bibliothèques et plates-formes d'entreprise.
Auparavant, les bibliothèques standard pour différents langages étaient assez petites et facilement répliquées-C, C++, assembleur, ML,LISP, etc.. est venu avec les bases, mais avait tendance à poulet quand il est venu à la normalisation sur des choses comme les communications réseau, cryptage, Graphiques, données les formats de fichiers (y compris XML), même les structures de données de base comme les arbres équilibrés et les tables de hachage ont été laissés de côté!
Les langages modernes comme Python, PHP, Ruby et Java viennent maintenant avec une bibliothèque standard beaucoup plus décente et ont beaucoup de bonnes bibliothèques tierces que vous pouvez facilement utiliser, en grande partie grâce à leur adoption d'espaces de noms pour empêcher les bibliothèques de se heurter les unes aux autres, et garbage collection pour standardiser les schémas de gestion de
Ces paradigmes ne doivent pas nécessairement s'exclure mutuellement. 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 assortir le style fonctionnel / poo / 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 passer les autour comme paramètres, avec un tas d'autres capacités. Ils peuvent faire des choses puissantes avec quelques 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, ce qui 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. Donc, vous pouvez avoir une fonction qui contient du code de procédure, mais vous pouvez le transmettre tout comme langues fonctionnelles.
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 passer cet objet.
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 aussi. D'un autre côté, des choses comme le traitement des chaînes peuvent être faites avec beaucoup moins de frais généraux et donc plus simple avec un paradigme procédural simple.
Je ne pense pas que ce soit une question de langue non plus. Vous pouvez écrire fonctionnel, procédural ou orienté objet dans presque n'importe quel langage populaire, bien qu'il puisse en être effort supplémentaire dans certains.
Pour répondre à votre question, nous avons besoin de deux éléments:
- compréhension des caractéristiques des différents styles/modèles d'architecture.
- compréhension des caractéristiques des différents paradigmes de programmation.
Une liste des styles/modèles d'architecture logicielle est affichée sur l'article architecture logicielle sur Wikipeida. Et vous pouvez effectuer des recherches sur eux facilement sur le web.
En bref et en général, la procédure est bonne pour un modèle qui suit une procédure, POO est bon pour la conception, et fonctionnel est bon 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 tous les deux, vous pouvez lier les éléments des styles/modèles d'architecture aux paradigmes de programmation.
Je pense qu'ils ne sont 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 proprement. Cependant, pour utiliser CUDA, vous devez utiliser C, qui ne prend pas en charge inheritance. Par conséquent, vous avez besoin d'être intelligent.
A) vous concevez un système intelligent qui émulera l'héritage dans une certaine mesure. Il peut être fait!
I) Vous pouvez utiliser un crochet, qui attend chaque enfant C de parent P pour avoir un certain remplacement pour la fonction F. Vous pouvez faire en sorte que les enfants enregistrent leurs remplacements, qui seront stockés et appelés si nécessaire.
Ii) vous pouvez utiliser la fonction struct memory alignment 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 il n'y a aucune garantie que vous ne rencontrerez pas de problèmes à mi-chemin du projet. Mettre héritage multiple est encore plus difficile, voire presque impossible.
B) vous pouvez utiliser une politique de nommage cohérente et utiliser l'approche divide and conquer pour créer un programme. Il n'aura aucun héritage, mais parce que 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 façon de codage ninja est la façon C de codage. 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 à l'approche B. j'ai écrit une solution possible en utilisant l'approche a, et je serai honnête, cela ne me semblait pas naturel d'utiliser ce code.