You know those times when you’re working on a program, and there are some places in your code that, depending on the requirements or a bug that manifests itself in some way, is directly related to the fact that you have multiple objects writing data to the same data store? That’s not a good thing.

That’s a terrible way to start a post. Let me try that again.

Multiple Objects Writing Data

Say you’re working on a program and one of the things the code does is update a counter somewhere in the database to track how many changes have occurred over a small period of times.

The problem: You’ve got multiple places in the code that are updating this counter.

Multiple Objects Writing Data

Multiple Objects Writing Data (In case my handwriting is as illegible as it appears).

I don’t think many of us set out to write code like this, but it happens, and when it does it ends up having all of these side effects that just breed all kinds of funky behavior. (I don’t know the official, academic term for it – and I don’t mean DRY – but I’m okay with “funky behavior” for this post.)

We know intuitively that we should have a single place in which all of this is happening, external factors – be it scope creep, a misunderstanding on our part to understand the requirements, or whatever – breed poor coding.

So then we have all of these entities throughout our system each of which is talking to a single point in our database (or whatever data store you like), but none of them are aware that others are speaking to them.

Set Up Boundaries

We can try to combat this with conditionals and what not, but we’re only making it worse. So what are we supposed to do?

I know, as with many things in programming, there are a variety of ways to solve this, but perhaps one of the first passes of refactoring is to have a class responsible for issuing updates to the datastore.

That way, we can go from the illustration above into something like this:

Multiple Objects Writing Data: Send it to a mediator of sorts.

Multiple Objects Writing Data: Send it to a mediator of sorts.

That is, all of the entities community with this object and this object – and only this object can read and write data to the database.

There are a few of design patterns that would fit this particular problem, but that’s outside the scope of this post. Instead, the point that I’m trying to make is that if you find yourself faced with a problem of:

  • Entities are writing data to the data store,
  • Multiple entities are doing it,
  • And it’s breeding unintended consequences,

Then try to create a class or set of class strictly responsible for reading and writing data. Only let the information pass through those classes rather than having multiple classes do the data manipulation.

It makes it easier to test, it makes it easier to debug, and it ultimately makes it easier to read.


    Leave a Reply