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

Question

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

Exemples d'architecture apprécié!

Answer 1

Tous sont bons à leur manière - Ils sont tout simplement des approches différentes pour les mêmes problèmes

.

Dans un style purement procédural, les données ont tendance à être très découplée des fonctions qui fonctionnent dessus.

Dans un style orienté objet, les données tend à transporter avec une collection de fonctions.

Dans un style fonctionnel, les données et les fonctions tendent à avoir plus en commun les uns avec les autres (comme dans Lisp et Scheme) tout en offrant une plus grande flexibilité en termes de la façon dont les fonctions sont effectivement utilisées. Les algorithmes ont également tendance à être défini en termes de récursion et de la composition plutôt que des boucles et itération.

Bien sûr, la langue elle-même que des influences dont le style est préféré. Même dans une langue pure fonctionnelle comme Haskell, vous pouvez écrire dans un style de procédure (bien que ce soit très découragée), et même dans un langage procédural comme le C, vous pouvez programmer dans un style orienté objet (comme dans le GTK + et API EFL).

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

Le choix que vous utilisez est tout simplement ce qui est plus logique pour votre projet et les abstractions votre langue prend en charge.

Answer 2

Je pense que les bibliothèques disponibles, des outils, des exemples et des communautés Trumps complètement le paradigme de nos jours. Par exemple, ML (ou autre) pourrait être le nec plus ultra programmation tout usage langue mais si vous ne pouvez pas obtenir de bonnes bibliothèques pour ce que vous faites, vous êtes foutus.

Par exemple, si vous faites un jeu vidéo, il y a plus de bons exemples de code et SDKs en C ++, alors vous êtes probablement mieux avec ça. Pour une petite application web, il y a quelques grands cadres Python, PHP et Ruby qui va vous permettre et en cours d'exécution très large rapidement. Java est un excellent choix pour les grands projets en raison de la compilation et la vérification des bibliothèques d'entreprise et les plates-formes.

Il fut le cas que les bibliothèques standard pour les différentes langues étaient assez petites et faciles à reproduire - C, C ++, Assembleur, ML, LISP, etc .. est venu avec les bases, mais ont eu tendance à le poulet quand il est venu la standardisation des choses telles que les communications de réseau, le cryptage, les graphiques, les formats de fichiers de données (y compris XML), même des structures de données de base comme des arbres équilibrés et hashtables ont été laissés!

langues modernes comme Python, PHP, Ruby et Java viennent maintenant avec une bibliothèque standard beaucoup plus décent et ont de bonnes bibliothèques de tiers, vous pouvez facilement utiliser, en grande partie grâce à leur adoption espaces de noms pour les bibliothèques d'entrer en collision avec un autre, et la collecte des ordures pour normaliser les systèmes de gestion de la mémoire des bibliothèques.

Answer 3

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 assortir le style fonctionnel / oop / procédure en un seul morceau de code.

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

Alors que dans un langage procédural comme le C, la seule façon que vous pouvez passer des fonctions est de l'ordre en utilisant des pointeurs de fonction, et que seule ne permet pas de tâches puissantes.

En python, une fonction est un citoyen de première classe, mais il peut contenir un nombre arbitraire de déclarations. Ainsi, vous pouvez avoir une fonction qui contient le code de procédure, mais vous pouvez le passer autour comme les langages fonctionnels.

Idem pour 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 autour de l'envelopper dans un objet qui implémente cette fonction, et ensuite passer cet objet autour.

En Python, vous n'avez pas cette restriction.

Answer 4

Pour GUI, je dirais que la Paradigma orientée objet est très bien adapté. La fenêtre est un objet, les objets sont Encadrés et le bouton OK est un aussi. Sur les autres trucs à la main, comme String Le traitement peut être fait avec beaucoup moins de frais généraux et donc plus simple avec paradigma procédure simple.

Je ne pense pas que ce soit une question de la langue non plus. Vous pouvez écrire fonctionnelle, procédurale ou orientée objet dans presque toutes les langues populaires, bien qu'il puisse être un peu d'effort supplémentaire dans certains pays.

Answer 5

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

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

Une liste de styles d'architecture logiciel / modèle est affiché sur le sur Wikipeida. Et vous pouvez rechercher sur eux facilement sur le web.

En bref et général, de procédure est bon pour un modèle qui fait suite à une procédure, OOP est bon pour la conception et fonctionnelle est bon pour la programmation de haut niveau.

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

Après les comprendre à la fois, vous pouvez lier les éléments de styles / modèles d'architecture aux paradigmes de programmation.

Answer 6

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 mots à la mode. Il y a peu de gens qui savent réellement ce « orienté objet » signifie, même si elles sont les évangélisateurs de plus farouches il.

Answer 7

Un de mes amis est écrit une application graphique en utilisant NVIDIA CUDA . L'application s'intègre très bien avec paradigme OOP et le problème peut être décomposé en modules soigneusement. Toutefois, pour utiliser CUDA vous devez utiliser C, qui ne prend pas en charge héritage . , Vous devez donc être intelligent.

a) méditez un système intelligent qui émuler l'héritage dans une certaine mesure. Il peut être fait!

i) Vous pouvez utiliser un système de crochet qui attend chaque enfant C de parent P d'avoir une certaine dérogation pour la fonction F. Vous pouvez faire enregistrer leurs enfants préséances, qui seront stockés et appelés en cas de besoin.

ii) Vous pouvez utiliser struct alignement mémoire fonctionnalité pour jeter les enfants dans les parents.

Cela peut être propre mais il est difficile de trouver à l'épreuve, solution fiable. Vous passerez beaucoup de temps à la conception du système et il n'y a aucune garantie que vous ne rencontrerez pas de problèmes à mi-chemin à travers le projet. La mise en œuvre héritage multiple est encore plus difficile, sinon presque impossible.

b) Vous pouvez utiliser la stratégie de nommage cohérente et utiliser diviser et conquérir l'approche pour créer un programme. Il n'aura pas d'héritage, mais parce que vos fonctions sont petites, faciles à comprendre et toujours formaté vous n'avez pas besoin. La quantité de code que vous devez écrire monte, il est très difficile de rester concentré et ne pas succomber à des solutions faciles (hacks). Cependant, cette façon de ninja de codage est la voie C de codage. Rester en équilibre entre la liberté de bas niveau et l'écriture du 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.

Je tends vers une approche b. J'ai écrit une solution possible à l'aide d'une approche, et je serai honnête, il se sentait très naturel en utilisant ce code.