• Sun
    August 8, 2008

Where's the State?

Guest Author

 from Tim Boudreau's Blog

 Where's the state? This is a small but useful question when
deciding how a problem domain gets carved up into objects:
What things have state? What things have values that
can change? When and how can they change? Can the changes be
observed? Who needs to observe changes in state?

These questions make a good start for figuring out how to carve
up a problem domain into objects, if you observe the principlekeep all related state in one place. I would go so far as to say
that the majority of the appeal of Model-View-Controller (MVC)
architecture is that it encourages you to keep state in one place.

One big reason why statefulness matters is threading.
In practice, it is common to see designs where threading was an
afterthought. This is
to be expected. Concurrency is a not natural way for human
beings to think. So commonly a library is designed with
no thought about threading;
then a problem shows up which multi-threading can solve.
Threading ends up being introduced into a codebase that was never
designed for it. Retrofitting a threading model on something designed
without one is very painful and sometimes impossible.

Some threading models can be simple. For example, any time you are
writing a Swing application, and you have a method that can do long
running I/O, the first line of that method should be

assert !EventQueue.isDispatchThread();

under all circumstances.

But keeping I/O off the event thread is the trivial case. Managing
mutations to a model inside an application
is a more complicated, less obvious problem.


Any time you find yourself writing a setter (or more generally,
mutator) method, it is worth asking yourselfWho does this piece of state really belong to? Am I putting
state in the right place?
Blindly following the beans pattern
(add a getter/setter to whatever type you happen to be editing)
can result in state being distributed all over objects in an
application. The result will be harder to maintain, and if it
has any lifespan, less and less maintainable
over time. Like entropy, or theno
broken windows theory
, the more state is distributed all
over the place, the more that will masquerade as design and
make it okay for a programmer to further diffuse state throughout
objects in the application. Human beings can only hold so many
things in their minds
at a time. The more state is diffused,
the more things someone must pay attention to simultaneously to
solve a problem in that code.

Read the rest of this blog . . .

Join the discussion

Comments ( 4 )
  • miguel Tuesday, September 2, 2008


  • miguel Tuesday, September 2, 2008

    es muy bueeno y espero tener mejoras en el sistema

  • miguel Tuesday, September 2, 2008


  • miguel Tuesday, September 2, 2008

    I`S GOOD

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.