Quel est l'avantage de la programmation orientée objet par rapport à la programmation procédurale?


77

J'essaie de comprendre la différence entre les langages procéduraux comme le C et les langages orientés objet comme le C ++. Je n'ai jamais utilisé le C ++, mais j'ai discuté avec mes amis de la façon de différencier les deux.

On m'a dit que C ++ utilisait des concepts orientés objet ainsi que des modes public et privé pour la définition de variables: ce que C n'a pas. Je n'ai jamais eu à les utiliser pour développer des programmes dans Visual Basic.NET: quels en sont les avantages?

On m'a également dit que si une variable est publique, elle peut être consultée n'importe où, mais on ne voit pas clairement en quoi elle diffère d'une variable globale dans un langage tel que C. Il est également difficile de savoir en quoi une variable privée diffère d'une variable locale.

Une autre chose que j'ai entendue est que, pour des raisons de sécurité, si une fonction doit être utilisée, elle doit d'abord être héritée. Le cas d'utilisation est qu'un administrateur devrait avoir uniquement le nombre de droits dont il a besoin et pas tout, mais il semble qu'un conditionnel fonctionnerait également:

if ( login == "admin") {
    // invoke the function
}

Pourquoi n'est-ce pas idéal?

Étant donné qu'il semble exister un moyen procédural de faire tout ce qui est orienté objet, pourquoi devrais-je me préoccuper de la programmation orientée objet?




26
+1 pour contrer certains votes négatifs. Si un collègue me posait une telle question, j'aurais probablement des inquiétudes et je pourrais même le renverser (en supposant qu'il y ait une sorte de flèche vers le bas à côté de lui). Cependant, cette question semble avoir été posée par un futur ingénieur logiciel et il semblerait qu’il ait passé un certain temps à réfléchir et à discuter du sujet avant de poster. Je vote pour l'aider plutôt que de le congédier.
DXM

14
@DXM Excellente idée! Des flèches downvote / upvote flottant autour de vos collègues ... Cela ferait des merveilles.
Yannis

2
Contre argument standard: Il existe également une méthode assembleur pour faire tout ce que vous pouvez faire en C, alors pourquoi devriez-vous vous soucier de C? (Astuce: il s'agit avant tout d'augmenter le niveau d'abstraction. C ++ parvient à le faire sans sacrifier l'essentiel de la vitesse de C. OMI, c'est la raison principale du succès de C ++.)
sbi

Réponses:


135

Jusqu'à présent, toutes les réponses se sont concentrées sur le sujet de votre question comme indiqué, à savoir "quelle est la différence entre c et c ++". En réalité, il semble que vous sachiez quelle est la différence, vous ne comprenez tout simplement pas pourquoi vous auriez besoin de cette différence. Alors, d’autres réponses ont tenté d’expliquer l’OA et l’encapsulation.

Je voulais ajouter une autre réponse car, en fonction des détails de votre question, je pense que vous devez prendre plusieurs mesures en arrière.

Vous ne comprenez pas le but de C ++ ou de OO, car pour vous, il semble que votre application ait simplement besoin de stocker des données. Ces données sont stockées dans des variables. "Pourquoi voudrais-je rendre une variable inaccessible? Maintenant, je ne peux plus y accéder! En rendant tout public ou, mieux encore, global, je peux lire des données de n'importe où et il n'y a pas de problèmes." - Et vous avez raison, compte tenu de l'ampleur des projets que vous écrivez actuellement, il n'y a probablement pas beaucoup de problèmes (ou il y en a, mais vous ne vous en êtes pas encore rendu compte).

Je pense que la question fondamentale à laquelle vous devez réellement répondre est la suivante: "Pourquoi voudrais-je jamais cacher des données? Si je le fais, je ne peux pas travailler avec!" Et c'est pourquoi:

Disons que vous démarrez un nouveau projet, ouvrez votre éditeur de texte et commencez à écrire des fonctions. Chaque fois que vous avez besoin de stocker quelque chose (pour vous en souvenir plus tard), vous créez une variable. Pour simplifier les choses, vous rendez vos variables globales. Votre première version de votre application fonctionne très bien. Maintenant, vous commencez à ajouter plus de fonctionnalités. Vous avez plus de fonctions, certaines données que vous avez stockées auparavant doivent être lues à partir de votre nouveau code. D'autres variables doivent être modifiées. Vous continuez à écrire plus de fonctions. Ce que vous avez peut-être remarqué (ou, sinon, vous remarquerez absolument dans le futur), c’est que plus votre code grossit, plus il vous faudra de plus en plus pour ajouter la fonctionnalité suivante. Et à mesure que votre code grossit, il devient de plus en plus difficile d'ajouter des fonctionnalités sans endommager quelque chose qui fonctionnait auparavant. Pourquoi? Parce que vous devez vous rappeler ce que toutvos variables globales sont le stockage et vous avez besoin de se rappeler où tous d'entre eux sont en cours de modification. Et vous devez vous rappeler quelle fonction peut appeler dans quel ordre exact . Si vous les appelez dans un ordre différent , vous risquez de recevoir des erreurs car vos variables globales ne sont pas encore tout à fait valides. Avez-vous déjà rencontré cela?

Quelle est la taille de vos projets typiques (lignes de code)? Imaginez maintenant un projet 5000 à 50000 fois plus grand que le vôtre. En outre, plusieurs personnes y travaillent. Comment tous les membres de l'équipe peuvent-ils se souvenir (ou même être au courant) de ce que font toutes ces variables?

Ce que j'ai décrit ci-dessus est un exemple de code parfaitement couplé. Et depuis la nuit des temps (à partir du 1er janvier 1970), le genre humain a cherché des moyens d'éviter ces problèmes. Pour les éviter, divisez votre code en systèmes, sous-systèmes et composants et limitez le nombre de fonctions ayant accès à n'importe quelle donnée. Si j'ai 5 entiers et une chaîne représentant une sorte d'état, est-ce que ce serait plus facile pour moi de travailler avec cet état si seulement 5 fonctions définissaient / obtenaient les valeurs? ou si 100 fonctions définissent / obtiennent ces mêmes valeurs? Même sans les langages OO (c.-à-d. C), les utilisateurs ont travaillé dur pour isoler les données d’autres données et pour créer des limites de séparation nettes entre les différentes parties du code. Lorsque le projet atteint une certaine taille, la facilité de programmation ne devient plus "puis-je accéder à la variable X à partir de la fonction Y",

C'est pourquoi les concepts OO ont été introduits et pourquoi ils sont si puissants. Ils vous permettent de cacher vos données à vous-même et vous voulez le faire exprès, parce que moins de code voit ces données, moins il y a de chance que, lorsque vous ajoutez la fonctionnalité suivante, vous cassez quelque chose. C'est l'objectif principal des concepts d'encapsulation et de programmation orientée objet. Ils vous permettent de décomposer nos systèmes / sous-systèmes en des zones encore plus granulaires, à un point tel que, quelle que soit la taille du projet, un ensemble de variables donné ne peut être accédé que par 50-200 lignes de code, et c'est tout! Il y a évidemment beaucoup plus à la programmation OO, mais c'est essentiellement pour cette raison que C ++ vous offre des options pour déclarer des données / fonctions en tant que données privées, protégées ou publiques.

La deuxième idée la plus importante chez OO est le concept de couches d'abstraction. Bien que les langages procéduraux puissent également avoir des abstractions, en C, un programmeur doit faire un effort conscient pour créer de telles couches, mais en C ++, lorsque vous déclarez une classe, vous créez automatiquement une couche d'abstraction (c'est à vous de décider si cette abstraction ajoutera ou supprimera une valeur). Vous devriez lire / rechercher plus sur les couches d'abstraction et si vous avez plus de questions, je suis sûr que ce forum sera ravi de répondre à celles-ci également.


5
Grande réponse, semble atteindre le niveau approprié étant donné la question
Carlos

29
+1 ... principalement pour la ligne "Et depuis la nuit des temps (à partir du 1er janvier 1970) ..." ligne
CaffGeek

4
@Chad - Je pensais que cette ligne seule devrait me rapporter au moins un point :)
DXM

Il y a une façon de traiter ce problème d'échelle dont vous parlez dans le paradigme procédural. Cela s'appelle des fonctions. Mais bon moyen d’expliquer le problème.
annoying_squid

@DXM - Je ne suis pas sûr d'avoir bien compris la réponse. Nous pouvons également obtenir la même fonctionnalité set / get dans la programmation procédurale. Nous pouvons écrire des fonctions set / get en C pour modifier / obtenir la variable globale. En utilisant également cette méthode, nous limitons le nombre de fonctions modifiant les variables globales. Et même en POO, si nous utilisons également les méthodes set / get, nous les utiliserons de l'extérieur de l'objet pour modifier les valeurs.
kadina

10

Hmm ... il est peut-être préférable de sauvegarder et d'essayer de donner une idée de l'intention de base de la programmation orientée objet. Le but de la programmation orientée objet est de permettre la création de types de données abstraits. Pour un exemple très simple avec lequel vous êtes certainement familier, considérons une chaîne. Une chaîne aura généralement un tampon pour contenir le contenu de la chaîne, certaines fonctions pouvant agir sur la chaîne (rechercher dans une chaîne, y accéder en partie, créer des sous-chaînes, etc.). Elle aura également (du moins généralement) quelque chose à garder une trace de la longueur (actuelle) de la chaîne et (probablement) de la taille de la mémoire tampon; ainsi, si (par exemple) vous augmentez la taille de la chaîne de 1 à 1000000, elle saura quand elle aura besoin de plus de mémoire pour contenir la plus grande contenu.

Ces variables (le tampon, la longueur actuelle et la taille du tampon) sont privées de la chaîne elle-même, mais elles ne sont pas locales pour une fonction particulière. Chaque chaîne a un contenu d'une certaine longueur, nous devons donc suivre ce contenu / cette longueur pour cette chaîne. Inversement, la même fonction (par exemple, extraire une sous-chaîne) peut opérer sur plusieurs chaînes différentes à des moments différents, de sorte que les données ne peuvent pas être locales à la fonction individuelle.

En tant que tel, nous nous retrouvons avec des données privées de la chaîne, de sorte qu’elles sont uniquement (directement) accessibles aux fonctions de chaîne. Le monde extérieur peut obtenir la longueur de la chaîne à l'aide d'une fonction chaîne, mais n'a pas besoin de connaître les éléments internes de la chaîne pour l'obtenir. De même, il peut modifier la chaîne - mais encore une fois, il le fait via les fonctions de chaîne, et seules celles-ci modifient directement les variables locales à l'objet chaîne.

En ce qui concerne la sécurité, je noterais que, même si cette analogie est raisonnable, ce n'est pas ainsi que les choses fonctionnent. En particulier, l’accès en C ++ n’est pas destiné à répondre au même type de besoins que l’accès dans un système d’exploitation. Un système d'exploitation est censé appliquer les restrictions afin qu'un utilisateur normal (par exemple) ne puisse pas faire les choses réservées à un administrateur. En revanche, le contrôle d’accès en C ++ n’est destiné qu’à la prévention des accidents. À dessein, quiconque le souhaite peut les contourner assez facilement. Ils sont dans le même ordre que marquer un fichier en lecture seule afin que vous ne le supprimiez pas accidentellement. Si vous décidez de supprimer le fichier, il est facile de passer de lecture seule à lecture-écriture; le configurer en lecture seule uniquement vous fait au moins y penser une seconde et décider de supprimer le fichier afin qu’il ne soit pas supprimé par accident simplement en appuyant sur la mauvaise clé au mauvais moment.


6

OOP versus C ne concerne pas vraiment les sujets dont vous avez discuté. Il s’agit principalement d’empaqueter du code dans des zones qui ne s’affectent pas / ne peuvent pas s’affecter involontairement (ou parfois même intentionnellement).

C vous permet essentiellement d’exécuter n’importe quelle fonction. La POO empêche cela en regroupant les méthodes dans des classes et en vous permettant uniquement de les utiliser en référençant la classe qui les contient. Donc, un gros avantage potentiel de la programmation orientée objet est qu'il est beaucoup plus probable que vous disposiez d'un meilleur agencement de code sans beaucoup d'expérience pour vous dire que vous devriez le faire.


4
-1. Il n'y a rien d'exclusif en C qui rend toutes les fonctions globales. Vous pouvez déclarer n'importe quelle fonction statique et limiter ainsi sa portée au fichier local. C n'est pas différent de C ++, Java, etc. dans cet aspect. En outre, la programmation orientée objet ne concerne pas la syntaxe de langage. Vous pouvez écrire des programmes OO en C, mais ils seront un peu plus rudimentaires que dans les langages prenant en charge la syntaxe pour OO. Et au contraire: vous n’obtenez pas la POO simplement parce que vous avez choisi une langue qui prend en charge OO. L'orientation objet est un style de programmation et non une fonctionnalité de langage.

@Lundin: Bien que vous ayez techniquement raison, vous avez mal compris. Les langages POO font en sorte que le comportement par défaut du comportement POO soit le comportement par défaut. C pas.
John Fisher

1
Rien dans les langues OO ne vous oblige à le faire. Par exemple, j'ai vu d'innombrables programmes C ++ obscurs sans aucun objet à mentionner. De même, si vous n'avez pas la moindre idée sur OO mais essayez d'implémenter des classes, du patrimoine, etc., il y a environ 100% de chances de créer un programme gâché.

@Lundin: Je ne pense pas que le C ++ soit un bon exemple. Il est (ou du moins était) destiné à pouvoir compiler des programmes C sans (beaucoup) de modification. L'ajout de classes en haut n'en fait pas un langage OOP de niveau C # ou Java, mais permet ce type de développement.
John Fisher

Vous pouvez aussi écrire des programmes non-OO en Java, tout simplement en un seul fichier énorme ... OO n'est toujours pas spécifique à une langue. Si le programmeur ne connaît pas OO, aucune langue au monde ne les sauvera.

4

Un cours bien écrit devrait être un petit "îlot de confiance": vous pouvez l'utiliser et supposer qu'il fait "ce qu'il faut" et qu'il vous protège des pièges courants. Cela fait d'une bonne classe un bloc de construction, beaucoup plus réutilisable comme un tas de fonctions et de variables, qui pourrait bien fonctionner mais vous montrer tout leur vilain courage, et vous obliger à comprendre comment elles fonctionnent ensemble, comment elles doivent être initialisées etc. Une bonne classe devrait ressembler à une prise USB, tandis que la solution procédurale ressemblerait à un tas de fils, de puces, d’étain et à un fer à souder.

Un point qui n'a pas été discuté en profondeur est l'aspect interface / implémentation. Une interface décrit le comportement, mais pas la réalisation. Donc, une interface de liste décrit le conceptd'une liste et de son comportement: Vous pouvez vous attendre à des choses comme des méthodes d'ajout, de suppression et de taille. Il existe maintenant de nombreuses façons différentes de mettre en oeuvre cette liste, par exemple en tant que liste chaînée ou en utilisant un tampon de tableau. La puissance de la programmation OO réside dans le fait qu’en utilisant une interface, vous pouvez raisonner sur le comportement sans connaître l’implémentation. L'accès à des variables ou méthodes internes détruirait cette abstraction, vous ne pourriez pas remplacer une implémentation de liste par une autre et vous ne pourriez pas améliorer une implémentation existante sans toucher au code à l'aide de la classe. C’est l’une des principales raisons pour lesquelles des méthodes et des variables privées sont nécessaires: Protéger les détails internes de l’implémentation afin que l’abstraction reste intacte.

OO va même plus loin: par exemple, pour les bibliothèques, vous pouvez définir une interface pour des éléments qui n'existent pas encore et écrire un code qui fonctionne avec cette interface. Les utilisateurs peuvent écrire des classes implémentant l'interface et utiliser les services fournis par la bibliothèque. Cela permet un degré de flexibilité impossible avec la programmation procédurale.


Le concept d'interface n'est pas unique aux langages orientés objet. Un facteur plus important, je pense, est que dans les langages non-POO, presque toutes les fonctions utilisées dans un module doivent appartenir au même espace de noms global. Cela nécessite soit de préfixer le nom de la fonction pour indiquer l’action sur laquelle il agit, soit d’avoir plusieurs méthodes similaires qui font des choses complètement différentes (par exemple, SetLocationpourraient être utilisées pour déplacer un Monster, alors que SetPositionpourraient être un PopupWindow, et Movepourraient être utilisées pour ajuster la position de a DisplayCursor). Essayer de trouver la bonne méthode "move" ...
Supercat

... peut être beaucoup plus facile si, quand on écrit, MyMonstor->l’éditeur ne montre qu’une liste de méthodes applicables aux choses de type Monster. S'il existe plusieurs dizaines d'éléments différents, chacun prenant en charge une douzaine d'opérations, la réduction de l'encombrement dans les listes de méthodes de 90% peut considérablement réduire la productivité.
Supercat

Les conflits de noms @supercat sont un problème de langue et non un problème non-POO. D'autre part, les espaces de noms sont problématiques car le compilateur doit essentiellement renommer la fonction automatiquement ou la modifier. Alors pourquoi ne pas le faire manuellement?
annoying_squid

@annoying_squid: Ce que la programmation orientée objet fournit est la possibilité d'utiliser efficacement le type d'argument principal d'un fonction pour sélectionner l'espace de nom. Si j'ai une variable itde type SuperFancyWhizBang, invoquer l'une des SuperFancyWhizBangméthodes de itne nécessite pas d'écrire le type SuperFancyWhizBang; Cette phrase it.woozle()demandera au compilateur de rechercher automatiquement à l' woozleintérieur SuperFancyWhizBang.
Supercat

3

Il existe un moyen de tout faire avec une machine Turing, ou au moins dans un langage d'assemblage pour le code machine qu'un programme C ou C ++ compilera éventuellement.

La différence ne concerne donc pas ce que le code peut faire, mais ce que les gens peuvent faire.

Les gens font des fautes. Beaucoup.

OOP introduit un paradigme et une syntaxe permettant de réduire la taille et la densité de probabilité de l'espace des erreurs de codage humaines possibles. Parfois, en rendant l'erreur illégale pour une certaine classe d'objets de données (par exemple, ce n'est pas une méthode déclarée pour cet objet). Parfois, en rendant l'erreur plus verbeuse ou stylistiquement étrange par rapport à l'usage canonique de la langue. Parfois, en exigeant une interface avec des utilisations beaucoup moins possibles incompatibles ou enchevêtrées (public ou privé). etc.

Plus le projet est important, plus le risque d'erreur est élevé. Ce qui pourrait ne pas exposer un nouveau codeur s’il est expérimenté avec de petits programmes. Ainsi, la perplexité potentielle quant à la raison de la programmation orientée objet est précieuse.


2

Votre question semble porter davantage sur le but de la programmation orientée objet que sur la différence. Le concept dans votre post est Encapsulation; et l'encapsulation existe pour supporter CHANGE. Lorsque d'autres classes accèdent à vos internes, il devient difficile de les modifier sans les casser. Dans OOP, vous fournissez une interface (membres publics) à travers laquelle vous autorisez d'autres classes à interagir avec la vôtre, et vous masquez vos éléments internes afin qu'ils puissent être modifiés en toute sécurité.


Il suffit d'utiliser des prototypes de fonctions. C'est encapsulation.
annoying_squid

2

Peu importe où je lis les variables privées et inaccessibles alors que les variables publiques peuvent l'être, pourquoi ne pas rendre public aussi global et privé que local quelle est la différence? Quelle est l'utilisation réelle de public et privé? s'il vous plaît ne dites pas qu'il peut être utilisé par tout le monde, je suppose pourquoi ne pas utiliser certaines conditions et effectuer les appels?

J'espère que vous ne voudrez jamais plus d'une chaîne dans votre application. J'espère également que vos variables locales persistent entre les appels de fonction. Ces choses pourraient être les mêmes en termes d'accessibilité, mais en termes de durée de vie et d'autres utilisations? Ils ne sont absolument pas les mêmes.


1

Comme beaucoup l'ont dit, tout programme, une fois compilé, est transformé en code binaire et, comme une chaîne binaire peut être utilisée pour représenter un entier, tout programme n'est finalement qu'un nombre. Cependant, définir le nombre dont vous avez besoin pourrait être assez difficile et c'est pourquoi les langages de programmation de haut niveau sont apparus. Les langages de programmation ne sont que des modèles du code d'assemblage qu'ils produisent éventuellement. Je voudrais vous expliquer la différence entre la programmation procédurale et la programmation orientée objet au moyen de ce très bel article sur la programmation contextuelle http://www.jot.fm/issues/issue_2008_03/article4/

Comme vous pouvez le voir sur cette image, illustrée dans le document, la programmation procédurale fournit une seule dimension pour associer une unité de calcul à un nom. Ici, les appels de procédure ou les noms sont directement mappés sur les implémentations de procédure. Dans Figure-a, l'appel de m1 ne laisse d'autre choix que l'invocation de la seule implémentation de la procédure m1.

La programmation orientée objet ajoute une autre dimension pour la résolution de noms à celle de la programmation procédurale. En plus du nom de la méthode ou de la procédure, l'envoi du message prend en compte le destinataire du message lors de la recherche d'une méthode. Dans la figure-b, nous voyons deux implémentations de la méthode m1. La sélection de la méthode appropriée dépend non seulement du nom du message m1, mais également du destinataire du message, ici Ry.

Ceci permet en effet l’encapsulation et la modularisation.

entrez la description de l'image ici

La figure c concerne enfin la programmation orientée sujet. Elle étend la répartition des méthodes orientées objet selon une autre dimension.

J'espère que cela vous a aidé à penser à la POO sous un angle différent.


0

(+1) Poser une question sur quelque chose que vous ne comprenez pas, c'est bien, même si cela semble idiot.

La différence est la programmation orientée objet et classe. "Plain C", fonctionne avec les données et les fonctions. "C ++" ajoute les concepts "objet et classes", ainsi que plusieurs concepts secondaires connexes.

Cependant, je conseille aux développeurs d'apprendre "Plain C" avant "C ++". Ou "Pascal procédural" avant "Object Pascal".

Beaucoup de développeurs pensent que les étudiants ne devraient enseigner qu’une chose.

Par exemple, les anciens enseignants qui ne reçoivent pas de OO et enseignent uniquement le "C structuré simple".

Ou des professeurs "hipster" qui n'enseignent que du OO, mais pas du "Plain C", parce que "vous n'en avez pas besoin". Ou les deux, sans se soucier de l'ordre d'enseignement.

Je pense plutôt que les étudiants devraient apprendre à la fois le "C organisé structuré" et le "C orienté objet (C ++)". Avec "Plain C", d'abord, et "C ++", plus tard.

Dans le monde réel, vous devez apprendre les deux paradigmes (ainsi que d'autres paradigmes, tels que "fonctionnel").

Penser des programmes structurés en tant que gros "objet" singleton peut aider.

Vous devez également mettre l'accent sur les espaces de noms ("modules"). Dans les deux langues, de nombreux enseignants l'ignorent, mais c'est important.


Les espaces de noms et les surcharges ne font que rendre le programme plus difficile à comprendre. Cela rend le processus d'identification sensible au contexte. Lorsque vous voyez foo()en C ++, il peut s’agir d’une fonction globale, d’une fonction de l’espace de noms actuel, d’une fonction de l’espace de noms que vous utilisez using, d’une méthode, d’une méthode héritée et, le cas échéant, de l’appel de la fonction. peuvent être résolus par une recherche de nom basée sur des arguments, et la même chose est vraie pour Java et C #. En C, il ne peut s'agir que d'une fonction statique dans le fichier source actuel ou d'une fonction provenant d'un en-tête.
Calmarius

Ecrire MODULE_Foo () partout peut être un fouillis visuel, mais au moins vous savez exactement de quelle fonction il s'agit.
Calmarius

@ Calmarius, la solution est clairement de ne rien nommer foo .

0

En un mot, la gestion de projet. Ce que je veux dire, c'est que C ++ m'aide à appliquer des règles sur la manière dont mon code est utilisé par d'autres. Travaillant sur un projet de 5,5 millions de lignes, je trouve la programmation orientée objet très utile. Un autre avantage est le compilateur qui fait que moi (et tous les autres) suivent certaines règles et détectent des erreurs mineures lors de la compilation. Tous les avantages théoriques sont là aussi, mais je voulais juste me concentrer sur des choses pratiques de tous les jours. Après tout, tout est compilé en code machine.


-1

La programmation orientée objet est une programmation procédurale, avec des boîtes.

En PP, vous avez une zone, un état, qui devient incroyablement grand au fur et à mesure que le projet se développe, ce qui provoque des effets secondaires chaque fois que vous oubliez une infime partie de cet état.

Dans OO, vous avez beaucoup de cases, beaucoup d'états et, à mesure que le projet se développe, les cases s'agrandissent un peu et le nombre de cases augmente beaucoup.

Il reste plus facile de regarder les petites cases, d'avoir l'illusion d'une image complète, mais en fait presque impossible, car regarder les classes et les interfaces cache les détails de l'implémentation qui peuvent avoir des conséquences importantes.

En programmation fonctionnelle, vous disposez de plusieurs boîtes à fonctions et décidez que chaque fonction possède une entrée (paramètres) et une sortie (retours), sans aucun autre accès au contexte extérieur.

Parce qu'il n'y a ni état ni effets secondaires (de par leur conception), vous pouvez analyser en toute sécurité toute fonction séparément du tout et savoir à 100% comment elle va se comporter, quelles que soient les circonstances.

Parce que vous boxez le code par unités logiques qui représentent des actions, il devient également possible de n’avoir qu’une boîte par action typique.

Cela réduira énormément le code de tout projet à grande échelle par rapport à la programmation orientée objet qui favorise le masquage de plusieurs fonctions analogiques sur la base de code dans différentes classes.

Cela dépassera également de loin PP, car vous pouvez prolonger le projet beaucoup plus longtemps car il n’ya plus d’état XXXXXXXL à suivre.

En résumé, PP est probablement le moyen le plus simple d'aborder un programme simple et la PF est probablement le moyen le plus simple d'aborder un programme complexe.

Si vous tenez compte de l’objectif de l’unification de toutes les bases de code et de l’amélioration de la réutilisation du code, vous devez toujours utiliser FP, car c’est le seul paradigme qui ait un sens à très grande échelle, ainsi que le seul qui offre une réutilisation à 100% (vous pouvez copiez-collez simplement une fonction et utilisez-la ailleurs, sans aucun frais supplémentaire.

Et vous bénéficiez gratuitement de tests unitaires fiables à 100%.

Et vous n'avez pas à écrire "final statique privé privé of_doom genius awesome string_1".

Et vous obtenez le parallélisme gratuitement.


-3

La simple différence d'une phrase est que C ++ est un langage C avec classes (bien que ce soit beaucoup plus maintenant), je ne comprends pas pourquoi vous ne voulez pas apprendre les différences entre les deux en lisant un excellent article sur C ++ sur Wikipedia .... .Cet article vous aidera beaucoup: - C ++ (Wikipedia)

Aussi googler sur la question aidera. Demander à des personnes aléatoires de l'expliquer peut être délicat. IMHO, on comprend mieux en lisant que de demander à quelqu'un


J'ai lu ceux-ci mais ils ont juste dit où ils étaient utilisés mais n'ont toujours pas résolu ma question.
Niko

Je n'ai pas posé la question sans faire d'efforts. J'ai cherché sur Google mais je suis toujours incapable de comprendre la différence. J'ai donc rencontré stackoverflow pour m'aider à résoudre ces
problèmes

1
@Nniko, vous vous trompez ici. Ce que je voulais dire, c'est que vous devriez essayer de comprendre la différence entre les deux en lisant. Demander à vos amis n'est pas bon. Parce qu'ils fourniront leur propre compréhension qui pourrait ne pas vous satisfaire. Mais ne vous inquiétez pas, il y a d'excellents pairs ici, ils vous aideront sûrement :-)
Pankaj Upadhyay

2
Je n'ai pas voté vers le bas, mais j'ai été très tenté par "C ++ is C with Classes". Ceux d’entre nous qui savent réellement utiliser le C ++ travaillent sans rien faire pour tenter de le sortir de la tête de gens.
DeadMG

1
@Pankaj: C'est vrai. Il était C avec des classes. Ce n’est certainement plus C avec Classes, et l’appeler ainsi a presque 30 ans de retard. C ++ a fait un très long chemin depuis lors. Les personnes qui codent maintenant C ++ ne le font jamais ainsi. Cela encourage les pires habitudes et la mauvaise impression.
DeadMG
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.