Les paradigmes non-POO prennent-ils en charge des concepts tels que l'encapsulation?

L'un des concepts importants de la programmation orientée objet est l'encapsulation. Cependant, récemment, le monde du logiciel semble pencher en faveur d'autres paradigmes comme la programmation fonctionnelle.

Cela me fait penser, qu'en est-il de l'encapsulation et des autres principes de la POO? Se trompent-ils?

Est-ce que la POO est mal appliquée? Par exemple, Alan Kay est connu pour avoir dit dans le discours de l'OOPSLA 97: "J'ai inventé le terme orienté objet, et je peux vous dire que je n'avais pas C ++ en tête."

Joe Armstrong - "Les objets lient les fonctions et les structures de données en unités indivisibles. Je pense que c'est une erreur fondamentale car les fonctions et les structures de données appartiennent à des mondes totalement différents."

Je pense que le piège dans lequel vous êtes tombé ici est de penser qu'il existe une définition rigide de tout paradigme de programmation (structuré, orienté objet, fonctionnel, et al.)

Si vous demandez à deux développeurs différents ce que signifie la POO, vous obtiendrez deux réponses différentes. Oui, en tant que profession, nous convenons qu'il existe quelques thèmes communs tels que l'encapsulation, la dissimulation de données, etc. couverts par tout cours de génie logiciel OOP au collège.

Cependant , dans le monde réel, les choses ne sont pas aussi simples et sèches, c'est pourquoi deux développeurs donneront deux réponses différentes. Ce sont peut-être des experts dans différentes langues qui expriment différemment les concepts de la POO. Les paradigmes linguistiques ont tendance à se chevaucher. La dernière rage depuis 2013 environ incorpore la programmation fonctionnelle dans les langages orientés objet via des fermetures ou des lambdas. Java 8 est-il orienté objet ou fonctionnel? Je l'appellerais orienté objet avec un tiret fonctionnel. Quelqu'un d'autre pourrait le décrire différemment.

Est-ce que la POO est mal appliquée?

Non, le problème est que différents langages expriment différemment les concepts de programmation. Peut-être qu'une langue exclut un concept de POO, et une autre langue l'inclut mais laisse de côté un concept de POO différent. Les langues sont généralement conçues dans un but: faciliter un certain type de tâche, au détriment de rendre d'autres tâches plus difficiles. Ce n'est ni bon ni mauvais, c'est simplement un compromis réel qui est impossible à éviter.

Le monde réel n'est pas la salle de classe. Soit nous devons discuter des paradigmes de programmation conceptuelle au niveau abstrait, soit nous devons discuter de vrais langages de programmation qui sont obligés de faire des compromis pour être utiles. Tant qu'un langage de programmation est principalement défini par une définition abstraite de la POO, nous pouvons l'inclure dans ce compartiment.

Cependant, récemment, le monde du logiciel semble pencher en faveur d'autres paradigmes comme la programmation fonctionnelle.

C'est discutable. Tout d'abord, je ne vois pas d'autres paradigmes en dehors de la programmation orientée objet et de la programmation fonctionnelle qui sont largement discutés, donc je suppose que nous pouvons oublier la phrase «d'autres paradigmes comme» , parlons de FP, rien d'autre.

Les raisons pour lesquelles la programmation fonctionnelle est devenue si populaire au cours des dernières années ont été discutées en détail ici dans d'autres questions, je ne vais pas répéter cela (voir ici ou ici , par exemple). Mais, à mon avis, ce n'est pas parce que "OOP était une grosse erreur", ou "Functional vs OOP s'excluent mutuellement", c'est plus comme des personnes étendant leur boîte à outils et essayant de tirer le meilleur parti des deux mondes. Ok, il y a sûrement des experts qui sont des extrémistes favorisant l'un sur l'autre, mais vous trouverez ces gars des deux côtés.

Cela me fait penser, qu'en est-il de l'encapsulation et des autres principes de la POO? Se trompent-ils?

L'encapsulation a de nombreuses saveurs différentes. Les langages de programmation fonctionnels et les constructions de langage fournissent certaines formes d'encapsulation, d'autres orientées objet. Si vous recherchez des exemples d'encapsulation avec des moyens fonctionnels, commencez par les fermetures .

Concernant les "autres principes": non, ils ne se trompent pas, mais pour certains scénarios comme la parallélisation à grande échelle, les approches fonctionnelles évoluent probablement mieux. Pour d'autres scénarios, comme la création de cadres d'interface utilisateur bien conçus, les approches OOP évoluent probablement mieux (YMMV, je n'ai pas seulement un meilleur exemple à portée de main). De plus, je suis sûr que pour la plupart des scénarios du monde réel, cela dépend des connaissances et de l'expérience de l'équipe avec son paradigme de programmation préféré à quel point un certain système évoluera.

Est-ce que la POO est mal appliquée? Par exemple, Alan Kay est connu pour avoir dit dans le discours de l'OOPSLA 97: "J'ai inventé le terme orienté objet, et je peux vous dire que je n'avais pas C ++ en tête."

Certes, la POO est souvent mal appliquée par de nombreuses personnes, mais je suis sûr que c'est la même chose pour la PF. Et je serais étonné si John Mc Carthy (concepteur de Lisp) avait quelque chose comme Javascript en tête quand il pensait à la programmation fonctionnelle (merci à moi, ne m'embrasez pas trop pour cette comparaison ;-)

Joe Armstrong - "Les objets lient les fonctions et les structures de données en unités indivisibles. Je pense que c'est une erreur fondamentale car les fonctions et les structures de données appartiennent à des mondes totalement différents."

Je suppose que l'inventeur d'Erlang a de bons arguments, mais il a aussi son propre point de vue, alors laissez-lui son opinion et construisez la vôtre. Il y a beaucoup d'autres experts qui ont une idée différente de cela.

Bien sûr:

struct Foo
{
    string bar;
    int bux;
}

Je sais ce que vous allez dire: "Mais cela n'encapsule pas aussi le comportement!" Eh bien, je suis avec Joe Armstrong sur celui-ci: vous pouvez écrire des programmes entiers ou des systèmes d'exploitation sans jamais avoir besoin d'objets de première classe. Linux le prouve.

Les programmeurs Javascript encapsulent régulièrement l'état et le comportement dans les fonctions et les fermetures, pas les classes.

Le principal problème ici est que l'encapsulation n'est pas un concept défini de manière rigide ni pourquoi il est utile. Faire des recherches montre que la façon dont les gens perçoivent l'encapsulation est très appréciée et que beaucoup de gens la confondent avec l'abstraction.

La première définition que vous allez trouver est

L'encapsulation est un concept qui relie les données et les fonctions qui manipulent les données ...

Si telle est votre définition, la majorité des langues ont la possibilité de regrouper les données et les fonctions opérant sur ces données en classes, modules, bibliothèques, espaces de noms, etc.

Mais je dirais que ce n'est pas le but principal de l'encapsulation, car cette définition continue:

..., et qui protège à la fois des interférences extérieures et des abus.

Wikipédia est également d'accord sur ce point:

Un mécanisme de langage pour restreindre l'accès direct à certains composants de l'objet.

Mais maintenant, nous devons nous demander ce que l'on entend par "ingérence et abus" et pourquoi l'accès direct aux données devrait-il être restreint. Je pense qu'il y a deux raisons.

Premièrement, il est dans l'intérêt du développeur de limiter la portée dans laquelle les données peuvent être mutées. Trop souvent, il est nécessaire d'avoir une logique avant / après la définition de la valeur. Et avoir seulement un nombre limité de lieux où la valeur peut être définie est extrêmement précieux. Dans les langages POO, cela peut être fait en utilisant des classes. Dans les langages fonctionnels "mutables", les fermetures ont le même objectif. Et parce que nous connaissons les classes = fermetures , il est même discutable que les langages fonctionnels mutables sont un "paradigme" différent de la POO.

Mais qu'en est-il des langues immuables? Il n'a pas de problème de mutation des variables. C'est là qu'intervient le deuxième problème: les fonctions de liaison et les données permettent de conserver ces données dans un état valide. Imaginez que vous ayez une structure immuable Email. Cette structure a un seul stringchamp. Nous avons des exigences selon lesquelles si vous avez une valeur de type, Emailce champ contient une adresse valide. Dans l'encapsulation OOP, cela se fait facilement en déclarant ce champ private, en fournissant uniquement la Getméthode et en ayantconstructor methodqui ne réussit que si passé dans la chaîne est une adresse valide. Même chose avec les fermetures. Maintenant, pour un langage immuable, il faudrait dire que la structure ne peut être initialisée que par une fonction spécifique et qu'une telle fonction peut échouer. Et je ne connais aucun langage qui répondrait à ces critères (peut-être que quelqu'un dans les commentaires peut m'éclairer).

Le dernier problème est ce que l'on entend par un langage "supportant" l'encapsulation. D'un côté, il existe des langages qui permettent d'appliquer l'encapsulation, de sorte que le code ne se compilera pas si l'encapsulation est rompue. De l'autre côté, le langage peut fournir un moyen de faire l'encapsulation, mais il ne l'impose pas, laissant le développeur le faire lui-même. Pour le deuxième cas, tout langage ayant des structures et des fonctions peut fonctionner. Les langages dynamiques et Haskell viennent à l'esprit. Et je dirais qu'il n'y a pas beaucoup de langues qui tombent de l'autre côté du spectre. Même C #, qui est vraiment bon pour appliquer l'encapsulation de ses objets, peut être contourné à l'aide de la réflexion. Mais voir cela en C # serait considéré comme une odeur de code massive et aucun développeur sain de C # ne le ferait volontiers.