2

The program is written in JavaScript. To give you a rough idea what I am thinking of:

function State() {
  return {
    color: 'green',
    size: 100,

    // ... there are other properties here
  }
}

function init() {
  const state = State()
  const otherObj = OtherObj()
  
  // ...something like an event fires `foo`
  foo(state, otherObj)
}

function foo(state, otherObj) {
  state.size = calcNewSize(state) // state changes
  state.color = pickNewColor(state, otherObj) // state changes
  // ...   
}

function pickNewColor(state, otherObj) {
  const someInformation = getSomeInformation(state)

  // ... do other stuff

  return newColor
}

const a1 = init()
const a2 = init()
const a3 = init()

Right now, I have 3 objects that I should pass from function to function, but I am wondering, if this would scale well.

I am also wondering, if it is better to pass the entire object, instead of only the properties that are needed by these functions. Maybe it would be a good idea, to draw a line at 2-3 arguments, and if more is necessary, then pass the entire object.

Also, this could possibly be refactored into a single class, with methods (like pickNewColor, getSomeInformation) having access to the properties (like size, color), in which case there wouldn't be any need to pass around objects. However, I was wondering, if the above approach of passing around objects could work well.

2
  • Can be unavoidable in open architectures (ex: the scene graph in a programmable game engine). But it can complicate things a lot with testing, reasoning about thread-safety, increased coupling, debugging, reusing the functions, etc. I find a lot of these problems substantially diminished if you can largely treat the state as immutable. For example, perhaps instead of foo inputting the state and mutating it in place, have it return a new state object without touching the original, making the function pure. – user377672 Oct 21 '20 at 1:53
  • In many cases though, I think it helps to just pass some more parameters, and that can also make it easier to implement pure versions of the functions that aren't mutating things in place. – user377672 Oct 21 '20 at 1:53
1

Some frameworks, like React, use this pattern. React and Redux get used together a lot. This sounds like it will tightly-couple your code.

Essentially you want to make a "demi-god" object or set of objects that store and manage application state. I used the word demi-god because you'll likely run into several issues associated with god objects like.

  1. Poor handling of concurrent events. Just like a god object, you're likely to have weird errors where the state magically changes on you, and there isn't an obvious reason why. You haven't guarded access to state variables, just broke them into multiple classes.

  2. Lots of state to pass around. Instead of passing 1 big object you're passing a bunch of small ones. If you have to pass several of them per screen you're you're essentially passing a god object piece by piece.

Your example looks kind of like some of the React tutorials before they explain Redux. I couldn't find an anti-pattern name for what you're doing, but it sounds like you'll couple almost all your classes together through these state objects (bad).

How can you abstract this state? How many objects will need to be refactored if you have a bug in the state objects? This is what highly coupled code looks like.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.