La décomposition fonctionnelle est-elle vraiment un contre-modèle?

Pendant que je lisais Les pires anti-patterns que vous ayez rencontrés , j'ai cliqué sur le lien dans ce post pour atterrir sur le site web sur les anti-patterns.

Et la page http://sourcemaking.com/antipatterns/functional-decomposition m'a fait réfléchir.

Quelle est la gravité de cet anti-modèle, et est-ce un anti-modèle du tout? Parce que, bien que je fasse principalement de la programmation OOP de nos jours, je ressens toujours une réticence contre les langages OOP purs comme Java, et aussi les pratiques de conception qu'ils apportent. Et je suppose que j'ai encore quelques traits de la programmation fonctionnelle pendant que j'écris le code.

Et cela a soulevé une question, est-ce que je me trompe en m'en tenant au style fonctionnel OOP +, ou est-ce courant dans l'industrie et n'est pas vraiment si mauvais.

Ce que je sais par expérience, c'est que le style fonctionnel OOP + n'est pas complètement compatible avec les développeurs OOP purs. Mais en même temps, alors que les développeurs OOP ont des problèmes avec le développement fonctionnel OOP +, le contre-argument est que les solutions OOP sont souvent trop conçues et trop difficiles à utiliser, et d'après mon expérience, n'étaient même pas un peu plus faciles, et en fait a introduit des angles morts pour cacher des bugs TRÈS graves.

Donc, même si j'ai discuté avec mon collègue de ces sujets, je suis arrivé à la conclusion qu'aucune des façons n'est réellement parfaite. Et j'ai toujours la question sans réponse.

Le problème de POO a également été renforcé par un lien d'un autre poste dans le même fil. Le lien examine la POO de style Java http://chaosinmotion.com/blog/?p=622

Quelle est donc l'attitude générale à l'égard du mélange de la programmation fonctionnelle avec la POO? Et quel est l'équilibre qu'un développeur devrait s'efforcer d'atteindre?

object-oriented functional-programming anti-patterns

— Codeur
source

Votre titre et votre corps de questions posent plusieurs questions connexes, mais entièrement différentes, dont certaines semblent rhétoriques. J'ai du mal à comprendre exactement ce que vous demandez ici.

— blueberryfields

Désolé, je ne suis pas un locuteur natif et j'ai du mal à penser à un meilleur titre. Les correctifs sont les bienvenus.

— Coder

La question est claire. N'écoutez pas les blueberryfields.

— jojo

De toute évidence, pour les fanatiques de la POO, tout ce qui est hors de portée de la POO est un «contre-modèle». En fait, le pire contre-modèle possible est une surutilisation excessive de la POO elle-même.

— SK-logic

Tout d'abord, la programmation fonctionnelle est actuellement ce que font tous les enfants sympas. L'Anti-Pattern parlait vraiment de programmation procédurale (ce serait plus clair si la technique était appelée "décomposition procédurale" mais ce n'est pas le cas), et je pense que vous l'étiez aussi.

L'anti-modèle parlait de mauvaises façons d'écrire du code procédural dans un langage orienté objet, l'autre page parlait de mal d'écrire Java - en vérité, il n'y a pas de langage si fantastique que vous pouvez faire tout ce que vous voulez mais ne pouvez pas écrire du mauvais code.

Dans la pratique, j'ai vu un peu plus d'ingénierie en code orienté objet que procédural - un peu moins en ingénierie et un peu plus en ingénierie.

Dans votre cas, cela dépendrait des détails, et je ne suis pas sûr de ce que vous faites réellement dans un style procédural. Est-ce correct, clair, testable, facile à modifier, etc.? Les critères pour juger le code devraient être basés sur ces préoccupations pratiques, et non sur la pureté d'un style particulier. Il semble que dans votre cas, des personnes raisonnables et bien informées pourraient être en désaccord (et le faire!) Sur ces préoccupations, et si c'est le cas, il n'y a probablement aucun moyen objectif de déterminer la vérité de la question.

— psr
source

Votre réponse a bien commencé, mais vous êtes devenu vague et sans engagement. J'ai lu l'article que l'OP était lié à la décomposition fonctionnelle, et c'est un horrible contre-modèle, pratiqué par les développeurs de procédures essayant de transformer leur style de programmation en un paradigme orienté objet. Donc non, cela ne dépend pas des spécificités.

— Robert Harvey

mais je ne pense pas que Coder pense que l'anti-pattern soit ce qu'il a personnellement fait (et je n'ai pas de raison particulière de douter de lui). Sa question (l'une d'entre elles, vraiment) était de savoir si la programmation de style procédural peut être OK dans un langage objet (probablement plus comme dans la fonction Java statique présentée dans le blog Java rant). Et cela dépend des détails de ce qu'il a codé. (J'ai fait une préface avec "Dans votre cas"). Je pense que vous lisez la question comme fondamentalement "Dois-je programmer comme dans l'anti-pattern?", Ce qui serait clairement mauvais - mais Coder le sait, je pense.

— psr

Même de cette façon - la décomposition procédurale est une technique valable, et la rejeter comme étant peu compatible avec la POO est un pur fanatisme. Laissez toutes les fleurs fleurir. Toutes les techniques sont valables si elles sont utilisées à bon escient. S'en tenir à une méthodologie particulière n'est pas du tout sage.

— SK-logic