Question

I hope I can phrase this question correctly. I have a concern when dealing with state and test-ability in classes with static and instance mutable fields.

Do the static fields essentially constitute a different class/responsibility/instance due to the difference in their lifetime/scope?

If so: then shouldn’t the instance fields also be a separate class/data structure?

And then: and if that is so, then shouldn’t all classes be stateless only receiving their dependencies on construction and should all then be immutable?

And finally, would this mean that functional programming is the right way to do object oriented programming as well?

Answer 1

You shouldn’t have (really) mutable static fields. That is crappy design. Functional programming makes things a lot easier. I would separate the concerns so:

• what is data, should only have the necessary code to manipulate it in class. like “string” “Integer” “Person” , these are the entities
• what manipulates data, depends on data, but should not have internal state (Formatters etc)
• what drives the execution , must usually have some internal state ,but it is either carried with the call, or is “configuration” like
  database connections, requests etc. This is either from an active
  request , or it is pure configuration (injected)
• what views results (pure views) should be stateless in itself, and state should be fed to it with a context
• then there is the glue in between which usually is the hairy exception..minimize that.

etc..

For testability

• data should be mockable to a fake database.
• “what manipulates data” should be easy to test since it is stateless.
• State contained in contexts is easy to mock.
• “what drives the execution” should be easy to test since dependencies are injectable and you can test it piece by piece.
• views are easy to test since mocked state can be fed to it. the difficulty comes from actually verifying “what it looks like” , but that is up to either gui automation or human testers.

In essence ALL of this could be done in a functional way if database (disk) and the request layer (web, ui, whatever) would comply. In practise you try to do the “pure” part in between pretty and functionalish , and use design patterns to shield it from the outside dirt.