ReduxはサニタイズされたGodオブジェクトパターンを使用していますか？

Reduxについて学びながら、God-objectパターン（またはアンチパターン）が思い浮かびました。両方とも、すべてのアプリデータとそれらを操作するメソッドを保持する単一の大きなオブジェクトを持っています。しかし、Reduxは、オブジェクトを不変にしたり、イベントを純粋な関数に厳密な署名を維持するなど、いくつかの制約を設けています。

そこで、ReduxはサニタイズしたバージョンのGodオブジェクトを使用していますか？または、Javascriptが強く型付けされた古典的なOOPではないことに関係がありますか？

redux

— グルシャン
ソース

短い答え：いいえ。長い答え（実際には答えにつながるはずの質問）：データベースはクラスですか？または、ファイルシステムはどうですか？またはキャッシュはどうですか？これらもすべて神のパターンですか？

— code4life

IMOはい、そうです。Reduxに関する最初の声明では、「JavaScriptの単一ページアプリケーションの要件がますます複雑になっているため、コードはこれまで以上に多くの状態を管理する必要があります。」-これは、アプリの状態を1つのBLOBとして管理する必要があることを意味します。これは、Webアプリに固有の問題であり、Webアプリの実装に使用される貧弱な/決して設計されていないフレームワークによって作成された問題だと思います。

— n13

@ n13：一元化された場所からアクセスできるからといって、それが1つの巨大なブロブであることを意味するわけではありません。たとえば、私のデータベースは集中管理された方法（DbContext）でアクセスされますが、その内部データはより小さな部分（テーブル、スキーマ）に分割されます。

— 18

@Flater多くのサブディビジョンを持つ大きなblobは、依然として大きなblobです。単純な古いオブジェクト指向モデルは、すべてのデータを必要に応じて区分化します。つまり、各オブジェクトは非常に少量の状態/データのみを扱い、すべてが非常に単純です。1つの巨大なグローバル構造体にすべてを保存することもできますが、ソフトウェアの設計が悪いため保存しません。ソフトウェア101

— N13

@ n13ロジックをサブクラス（非表示または非表示）に分離し、文字とグッドプラクティスの意図の両方に準拠しながら、ロジックへのアクセスを一元化できます。これは、マイクロサービスと単一のAPIを使用するのと同じ議論です。マイクロサービスはオプションですが、「通常の」REST APIが悪い習慣であることを意味するものではありません。

— 18

回答:

神オブジェクトとは何ですか？ウィキペディアから：

プログラムを含む[Godオブジェクト]の機能全体は、プログラム全体に関するほとんどの情報を保持し、このデータを操作するためのメソッドのほとんどを提供する単一の「全知」オブジェクトにコード化されます。このオブジェクトは非常に多くのデータを保持し、非常に多くのメソッドを必要とするため、プログラムでのその役割は神のようになります（すべてを認識し、すべてを包括する）。

Reduxストアには1つのデータオブジェクトのみが含まれ、2つまたは3つのメソッドのみが必要です。この点で、それを神のオブジェクトと考えることは想像しにくいです。明らかに「すべてを知っている」わけではありません。

レデューサーがまったく分割されていない場合、すべてのロジックが1つの関数内にある場合、それは修飾される可能性がありますが、状況を回避するためにレデューサーを小さなピースに分割するのは簡単なことです。

— ダニエル・T
ソース

OPは、すべてのレデューサーとストアを一緒に「神オブジェクト」としてカウントするかどうか疑問に思っています。

— user949300

プログラムのすべてのモデルクラスは、一緒に神オブジェクトとしてカウントされますか？

— ダニエルT.

従来のOOPでは、すべてが同じ「すべて」のデータを操作しているわけではないので、そうではありません。

— user949300

レデューサーは、すべてが同じ「すべて」のデータで動作するわけでもありません。単一のレデューサーは、単一のモデルクラスと同等です。レデューサーのデータはクラスのフィールドに相当し、アクションはクラスのメソッドに相当します（つまり、各caseステートメントは特定のメソッドに相当します。）

— ダニエルT.

IMO、上記の質問は発生しないはずです。関数型プログラミングの概念は、OOPSの概念に匹敵するものではなく、同じ問題を解決する異なる方法にすぎません。

— スティクシャン・デュベイ
ソース

質問のためだけにこの表画像を作成しましたか？テキストとしてより適していると思うので、読み込みが速くなり、スクリーンリーダーで観察できるようになります

— Phoenix

OOPは単方向のデータフローも促進しませんか？OOPが単に相互参照を保持できるクラスの概念であると考える場合を除き、双方向参照が通常設計の欠陥を示す適切な設計ではありません。

— スティーブンジュリス

OOPおよびFPで言及したもののほとんどは、最初の列の問題ステートメントとは関係ありません。例えば機能組成は、それが困難な状態の構造を理解することができ、それは変化だ

— スキー

あなたはFPを好むようですが、私の考えでは、あなたの答えはそれが神の物体であるという私の気持ちをちょっと確認します。OMGのように、プログラム全体の状態全体を1つの大きなものとして扱っているため、私の状態は非常に複雑です。はい、それは複雑です。OOPでは、更新される論理オブジェクトモデルがありますが、これは大したことではありません。非同期に発生する場合は、それでも問題ありません。ビューはオブジェクトの状態を反映し、実際には非常に簡単です。

— n13

最初のページでは、Reduxが単一ページWebアプリに固有の問題を解決することを非常に明確にしています。

JavaScriptの単一ページアプリケーションの要件がますます複雑になるにつれて、コードはこれまで以上に多くの状態を管理する必要があります。（Redux-モチベーションから）

私自身の翻訳は-WebアプリとWebアプリを作成するためのフレームワークが乱雑であり、ブラウザーで実行しているため、Webアプリ以外では発生しない独自の問題に直面しています。

誤解しないでください-Webアプリが悪い、またはフレームワークが悪いと言っているのではありません。Webページとそれに関する全体的なパラダイムが、アプリケーションを念頭に置いて設計されたことは間違いありません。一部のWebアプリは非常によく機能します。たとえば、Googleドキュメントが大好きです。ネイティブアプリの同等のものよりも優れています。

ただし、Reduxは、ブラウザーで実行するWebアプリの作成に起因する制限や問題に対処する必要がある場合に発生する問題を管理するための単なるツールです。

iOSアプリ、またはあらゆる種類のネイティブアプリの場合、意味がありません。オブジェクトモデルは、非同期の変更とユーザー操作を簡単に処理します。あなたは常に何が起こっているかを知ることができます。異なる状態のレンダリングは問題ではなく、MVCおよび更新イベントで自動化されます。

Webアプリのような状況に直面することはありません。

**アーキテクチャが悪い場合は、Reduxでさえ、何もあなたを救うことはできません;）

— n13
ソース