Использует ли Redux очищенный шаблон объекта God?

Когда я узнал о Redux, шаблон God-object (или anti-pattern) пришел мне на ум - оба имеют один большой объект, содержащий все данные приложения и методы для их манипулирования. Но Redux наложил некоторые ограничения, такие как сделать объект неизменным, а события - чистыми функциями, поддерживающими строгую подпись.

Таким образом, возник вопрос, использует ли Redux продезинфицированную версию объекта God? Или, как-то связано с тем, что Javascript не является классическим строго типизированным ООП?

redux Gulshan
источник

Краткий ответ: нет. Длинный ответ (на самом деле вопрос, который должен привести к ответу): база данных - это класс? Или как насчет файловой системы? Или как насчет кеша? Это тоже все паттерны Бога?

code4life

ИМО да, это так. В первом заявлении о Redux говорится: «Поскольку требования к одностраничным приложениям JavaScript становятся все более сложными, наш код должен обрабатывать больше состояний, чем когда-либо прежде». - это означает, что вы должны управлять состоянием своего приложения как одного большого двоичного объекта. Я думаю, что это проблема, характерная для веб-приложений и созданная бедными / никогда не предназначенными для этого средами, которые используются для реализации веб-приложений.

@ n13: просто потому, что это доступно из централизованного местоположения, не означает, что это, следовательно, один массивный шарик. Например, моя база данных доступна централизованно ( DbContext), но ее внутренние данные подразделяются на более мелкие части (таблицы, схемы).

Флэтер

@ Флатер - большая капля со многими подразделениями - все еще большая капля. Обычная старая ОО-модель разделяет все данные по необходимости, что означает, что каждый объект имеет дело только с очень небольшим количеством состояний / данных, и все довольно просто. Вы также можете хранить все в одной гигантской глобальной структуре, но вы не делаете этого, потому что это плохой дизайн программного обеспечения. Программное обеспечение 101.

13-18

@ n13 Вы можете разделить логику на подклассы (скрытые или нет), соответствовать как букве, так и намерениям хорошей практики, но при этом централизовать доступ к вашей логике. Это тот же аргумент, что и при использовании микросервисов против одного API. Хотя микросервисы являются опцией, это не означает, что «нормальный» REST API является плохой практикой.

Флэтер

Ответы:

Что такое объект Бога? Из Википедии:

Большая часть общей функциональности программы, содержащей [объект Бога], закодирована в единый «всезнающий» объект, который хранит большую часть информации обо всей программе, а также предоставляет большинство методов для манипулирования этими данными. Поскольку этот объект содержит так много данных и требует так много методов, его роль в программе становится подобной Богу (всезнающей и всеобъемлющей).

Хранилище Redux содержит только один объект данных и требует только 2 или 3 метода. В этом отношении трудно себе представить, что это объект Бога. Это определенно не «все знают».

Теперь, если ваш редуктор вообще не разбит, если вся логика находится в одной функции, тогда это может быть приемлемо, но просто разбить редуктор на несколько более мелких частей, чтобы избежать ситуации.

Даниэль Т.
источник

Я думаю, что OP задается вопросом , считаются ли все редукторы вместе с магазином «объектом Бога».

user949300

Все ли классы моделей программы вместе считаются объектом бога?

Даниэль Т.

Я бы сказал, что в традиционных ООП они не все работают с одними и теми же данными «всего», так что нет, это не так.

user949300

Редукторы также не все работают с одними и теми же данными «всего». Один редуктор эквивалентен одному классу модели. Данные редуктора эквивалентны полям класса, а действия эквивалентны методам класса (т. Е. Каждое выражение case эквивалентно определенному методу.)

Даниэль Т.

ИМО, вышеупомянутого вопроса возникнуть не должно. Концепции функционального программирования не сопоставимы с концепциями в OOPS, это просто разные способы решения одной и той же проблемы.

Сутикшан Дубей
источник

Вы сделали это изображение таблицы только для вопроса? Я думаю, что он лучше подходит для текста, так что он загружается быстрее и его можно увидеть с помощью программы чтения с экрана

Phoenix

Разве ООП также не стимулирует однонаправленный поток данных? Если вы не считаете, что ООП - это просто концепция классов, которые могут содержать ссылки друг на друга, но не надлежащий дизайн, где двунаправленные ссылки обычно указывают на недостаток дизайна.

Стивен Джеурис,

Большинство вещей, которые вы упоминаете в ООП и ФП, даже не имеют ничего общего с формулировкой задачи в первом столбце. Например, состав-функция только усложняет понимание структуры государства и его изменений

Ski

Кажется, вы предпочитаете FP, но, на мой взгляд, ваш ответ как бы подтверждает мое ощущение, что это объект Бога. Как и OMG, мое состояние настолько сложное, потому что я рассматриваю все состояние всей программы как одну большую вещь. Да, это сложно. В ООП у вас есть логические объектные модели, которые обновляются, что не имеет большого значения. Если это происходит асинхронно, это тоже хорошо. Представления отражают состояние объекта, и на практике это очень просто.

На первой странице совершенно ясно, что Redux решает проблему, характерную для одностраничных веб-приложений:

Поскольку требования к одностраничным приложениям JavaScript становятся все более сложными, наш код должен управлять большим количеством состояний, чем когда-либо прежде. (из Redux - Мотивация)

Мой собственный перевод - веб-приложения и платформы для создания веб-приложений грязны, и, поскольку они работают в браузере, они сталкиваются с уникальным набором проблем, которые просто не возникают вне веб-приложений.

Не поймите меня неправильно - я не говорю, что веб-приложения плохие или что фреймворки плохие. Просто веб-страницы и вся парадигма об этом, несомненно, никогда не были разработаны с учетом приложений. Некоторые веб-приложения работают на удивление хорошо - например, мне нравятся Google Docs, это лучше, чем нативные аналоги приложений.

Но Redux - это всего лишь инструмент для управления проблемами, возникающими, когда вам приходится сталкиваться с ограничениями и проблемами, возникающими при создании веб-приложений, работающих в браузере.

Для приложения iOS или любого другого приложения это не имеет смысла. Объектная модель легко обрабатывает асинхронные изменения и взаимодействие с пользователем. Вы всегда будете знать, что происходит. Рендеринг различных состояний не является проблемой и автоматизирован с помощью MVC и событий обновления.

Вы никогда не сталкивались с такой ситуацией, как веб-приложения.

** Если у вас плохая архитектура, то ничто не может вас спасти, даже Redux;)

n13
источник