Redux utilise-t-il un modèle d'objet Dieu aseptisé?

Tout en découvrant Redux, le modèle d'objet divin (ou anti-modèle) m'est venu à l'esprit - les deux ont un seul grand objet contenant toutes les données de l'application et les méthodes pour les manipuler. Mais Redux a mis quelques contraintes comme rendre l'objet immuable et les fonctions pures d'événements en maintenant une signature stricte.

Alors la question est venue, est-ce que Redux utilise une version aseptisée de l'objet Dieu? Ou, il y a quelque chose à voir avec Javascript qui n'est pas un POO classique fortement typé?

redux

— Gulshan
source

Réponse courte: non. Réponse longue (en fait une question qui devrait conduire à la réponse): une base de données est-elle une classe? Ou que diriez-vous d'un système de fichiers? Ou que diriez-vous d'un cache? Est-ce que ce sont tous des modèles de Dieu aussi?

— code4life

OMI, oui. C'est dans la première déclaration sur Redux: "Comme les exigences pour les applications JavaScript d'une seule page sont devenues de plus en plus compliquées, notre code doit gérer plus d'états que jamais." - cela implique que vous devez gérer l'état de votre application en un seul blob. Je pense que c'est un problème spécifique aux applications Web et créé par les cadres pauvres / jamais conçus pour cela qui sont utilisés pour implémenter les applications Web.

— n13

@ n13: Ce n'est pas parce qu'il est accessible à partir d'un emplacement centralisé qu'il s'agit donc d'un blob massif. Par exemple, ma base de données est accessible de manière centralisée ( DbContext) mais ses données internes sont subdivisées en parties plus petites (tableaux, schémas).

— Flater

@Flater une grosse goutte avec de nombreuses subdivisions est toujours une grosse goutte. Un ancien modèle OO simple compartimente toutes les données selon le besoin de savoir, ce qui signifie que chaque objet ne traite qu'une très petite quantité d'état / de données et que tout est assez simple. Vous pouvez également tout stocker dans une structure globale géante, mais vous ne le faites pas parce que c'est une mauvaise conception de logiciel. Logiciel 101.

— n13

@ n13 Vous pouvez séparer la logique en sous-classes (cachées ou non), respecter à la fois la lettre et l' intention de bonne pratique, tout en centralisant l'accès à votre logique. C'est le même argument que l'utilisation de microservices par rapport à une seule API. Bien que les microservices soient une option, cela ne signifie pas qu'une API REST "normale" est donc une mauvaise pratique.

— Flater

Réponses:

Qu'est-ce qu'un objet divin? De Wikipédia:

La plupart des fonctionnalités générales d'un programme [contenant un objet divin] sont codées en un seul objet "omniscient", qui conserve la plupart des informations sur l'ensemble du programme, et fournit également la plupart des méthodes de manipulation de ces données. Parce que cet objet contient tellement de données et nécessite tant de méthodes, son rôle dans le programme devient semblable à Dieu (omniscient et englobant).

Le magasin Redux ne contient qu'un seul objet de données et ne nécessite que 2 ou 3 méthodes. À cet égard, il est difficile d'imaginer le considérer comme un objet divin. Ce n'est décidément pas «tout savoir».

Maintenant, si votre réducteur n'est pas du tout cassé, si toute la logique est dans une seule fonction, alors cela pourrait être qualifié, mais il est simple de diviser le réducteur en un tas de petits morceaux pour éviter la situation.

— Daniel T.
source

Je pense que OP se demande si tous les réducteurs ensemble , plus le magasin, comptent comme un "objet divin".

— user949300

Est-ce que toutes les classes modèles d'un programme comptent ensemble comme un objet divin?

— Daniel T.

Je dirais que dans la POO traditionnelle, ils ne fonctionnent pas tous sur les mêmes données "tout", donc non.

— user949300

Les réducteurs ne fonctionnent pas tous sur les mêmes données "tout". Un seul réducteur équivaut à une seule classe de modèle. Les données du réducteur sont équivalentes aux champs de la classe et les actions sont équivalentes aux méthodes de la classe (c'est-à-dire que chaque énoncé de cas est équivalent à une méthode spécifique.)

— Daniel T.

OMI, La question ci-dessus ne devrait pas se poser. Les concepts de programmation fonctionnelle ne sont pas comparables aux concepts d'OOPS, ce sont juste des façons différentes de résoudre le même problème.

— Sutikshan Dubey
source

Avez-vous créé cette image de tableau juste pour la question? Je pense qu'il serait mieux adapté en tant que texte, afin qu'il se charge plus rapidement et puisse être observé avec un lecteur d'écran

— Phoenix

La POO n'encourage-t-elle pas également le flux de données unidirectionnel? Sauf si vous considérez la POO comme étant simplement le concept de classes qui peuvent contenir des références les unes aux autres, mais pas une conception appropriée où les références bidirectionnelles indiquent généralement un défaut de conception.

— Steven Jeuris

La plupart des choses que vous mentionnez sous OOP et FP n'ont même rien à voir avec l'énoncé du problème dans la première colonne. la fonction-composition, par exemple, ne fait que rendre plus difficile la compréhension de la structure de l'état et ses changements

— Ski

Il semble que vous préfériez la PF, mais dans mon esprit, votre réponse confirme un peu mon sentiment que c'est un objet divin. Comme OMG, mon état est si complexe, car je traite l'état entier de l'ensemble du programme comme une grande chose. Oui, c'est complexe. Dans la POO, vous disposez de modèles d'objets logiques qui sont mis à jour, ce qui n'est pas du tout un problème. Si cela se produit de manière asynchrone, c'est bien aussi. Les vues reflètent l'état de l'objet et c'est très simple en pratique.

— n13

La première page montre clairement que Redux résout un problème spécifique aux applications Web à page unique:

Comme les exigences pour les applications JavaScript à page unique sont devenues de plus en plus complexes, notre code doit gérer plus d'états que jamais auparavant. (de Redux - Motivation)

Ma propre traduction est la suivante: les applications Web et les cadres de création d'applications Web sont en désordre et lorsqu'ils s'exécutent dans un navigateur, ils sont confrontés à un ensemble unique de problèmes qui ne se posent tout simplement pas en dehors des applications Web.

Ne vous méprenez pas - je ne dis pas que les applications Web sont mauvaises ou que les cadres sont mauvais. C'est juste que les pages Web et tout le paradigme à ce sujet n'ont indéniablement jamais été conçus avec des applications à l'esprit. Certaines applications Web fonctionnent remarquablement bien - j'adore Google Docs par exemple, c'est mieux que les équivalents des applications natives.

Mais Redux n'est qu'un outil pour gérer les problèmes qui surviennent lorsque vous devez gérer les limitations et les problèmes qui découlent de la création d'applications Web qui s'exécutent dans un navigateur.

Pour une application iOS ou une application native de tout type, cela n'a aucun sens. Le modèle objet gère facilement les modifications asynchrones et l'interaction utilisateur. Vous saurez toujours ce qui se passe. Le rendu des différents états n'est pas un problème et est automatisé avec MVC et les événements de mise à jour.

Vous n'êtes jamais confronté à une situation comme les applications Web.

** Si votre architecture est mauvaise, eh bien, rien ne peut vous sauver, pas même Redux;)

— n13
source