17

While learning about Redux, the God-object pattern(or anti-pattern) came to my mind- both have a single big object holding all the app data and methods to manipulate them. But Redux has put some constraints like making the Object immutable and events pure functions maintaining strict signature.

So the question came, is Redux using a sanitized version of God object? Or, there is something to do with Javascript not being classical strongly typed OOP?

gnat
  • 21,442
  • 29
  • 112
  • 288
Gulshan
  • 9,402
  • 10
  • 58
  • 89
  • 2
    Short answer: no. Long answer (actually a question which should lead to the answer): is a database a class? Or how about a file system? Or how about a cache? Are these all God patterns, too? – code4life Dec 22 '17 at 13:48
  • IMO yes it is. It's in the first statement about Redux: "As the requirements for JavaScript single-page applications have become increasingly complicated, our code must manage more state than ever before." - this implies that you have to manage the state of your app as one blob. I think it's a problem specific to web apps and created by the poor / never-designed-for-this frameworks that are used to implement web apps. – n13 Sep 06 '18 at 09:22
  • @n13: Just because it's accessible from a centralized location doesn't mean that it's therefore one massive blob. For example, my database is accessed in a centralized way (`DbContext`) but its internal data is subdivided into smaller parts (tables, schemas). – Flater Sep 06 '18 at 12:58
  • @Flater a big blob with many subdivisions is still a big blob. A plain old OO model compartmentalizes all data on a need-to-know basis which means each object only deals with a very small amount of state/data and everything is pretty simple. You could also store everything in one giant global struct but you don't do that because it's bad software design. Software 101. – n13 Sep 13 '18 at 04:29
  • @n13 You can separate the logic into subclasses (hidden or not), comply with both the letter and the _intention_ of good practice, while still centralizing the acccess to your logic. It's the same argument as using microservices vs a single api. While microservices are an option, that doesn't mean that a "normal" REST API is therefore bad practice. – Flater Sep 13 '18 at 14:07

3 Answers3

6

What is a God object? From Wikipedia:

Most of [a God object containing] program's overall functionality is coded into a single "all-knowing" object, which maintains most of the information about the entire program, and also provides most of the methods for manipulating this data. Because this object holds so much data and requires so many methods, its role in the program becomes God-like (all-knowing and all-encompassing).

The Redux store only contains one data object and only requires 2 or 3 methods. In this respect it's hard to imagine thinking of it as a God object. It is decidedly not "all knowing."

Now if your reducer is not broken up at all, if all of the logic is in one function, then that might qualify but it's a simple matter to break up the reducer into a bunch of smaller pieces to avoid the situation.

Daniel T.
  • 3,013
  • 19
  • 24
  • I think OP is wondering if all the reducers **together**, plus the Store, count as a "God Object". – user949300 Jun 08 '18 at 23:43
  • 1
    Do all of a program's model classes *together* count as a god object? – Daniel T. Jun 09 '18 at 02:04
  • I'd argue that in traditional OOP they aren't all operating on the same "everything" data, so, no they aren't. – user949300 Jun 09 '18 at 02:38
  • Reducers also don't all operate on the same "everything" data. A single reducer is equivalent to a single model class. The reducer's data is equivalent to the class's fields and the actions are equivalent to the class's methods (I.e. each case statement is equivalent to a specific method.) – Daniel T. Jun 09 '18 at 10:55
  • I'd just like to add that Redux, Vuex, or the likes are often *mis*used _like_ God objects in that non-application state data/functionality end up there when it shouldn't. I've seen projects with stores that are *stuffed* with state/functionality suited for a component or service. I think this comes from countless contrived online examples/tutorials that tend to demo a progressive framework with it's store counterpart. Jr devs or noobies don't know any better and think it's 'essential' and then you get the above. – GHOST-34 Apr 15 '21 at 16:44
2

IMO, The above question should not arise. Functional programming concepts are not comparable to concepts in OOPS, they are just different ways of solving same problem. enter image description here

Anand
  • 181
  • 5
  • 5
    Did you make this table image just for the question? I think it would be better suited as text, so that it loads faster and can be observed with a screen reader – Phoenix Dec 21 '17 at 03:35
  • Doesn't OOP also encourage unidirectional data flow? Unless you consider OOP to be simply the concept of classes which can hold references to each other, but not proper design where bidirectional references typically indicate a design flaw. – Steven Jeuris Jun 04 '18 at 13:57
  • Most of the stuff that you mention under OOP and FP don't even have anything to do with the problem statement on the first column. function-composition for example only makes it harder to understand state structure and it's changes – Ski Jun 08 '18 at 16:53
  • It seems you prefer FP, but in my mind your answer just kinda confirms my feeling that it is a God object. Like OMG my state is so complex, because I'm treating the entire state of the entire program as one big thing. Yes, that's complex. In OOP, you have logical object models around that get updated which is not a big deal at all. If it happens asynchonously thats fine too. Views reflect the state of the object and it's very simple in practice. – n13 Sep 06 '18 at 09:20
0

The first page makes it abundantly clear that Redux solves a problem that is specific to single page web apps:

As the requirements for JavaScript single-page applications have become increasingly complicated, our code must manage more state than ever before. (from Redux - Motivation)

My own translation is - web apps and the frameworks for creating web apps are messy and as they're running in a browser they are faced with a unique set of problems that just don't arise outside of web apps.

Don't get me wrong - I am not saying web apps are bad, or that the frameworks are bad. It's just that web pages and the entire paradigm about it undeniably never was designed with applications in mind. Some web apps work remarkably well - I love Google Docs for example, it's better than the native app equivalents.

But Redux is just a tool to manage the problems that arise when you have to deal with the limitations and issues that come from creating web apps that run in a browser.

For an iOS app, or a native app of any kind, it doesn't make sense. Object model handles async changes and user interaction with ease. You'll always know what's going on. Rendering different states is not an issue and is automated with MVC and update events.

You're never faced with a situation like web apps are.

** If your architecture is bad, then well, nothing can save you, not even Redux ;)

n13
  • 161
  • 3