Using static class instead of client factory or dependency injection with gin?

Question

In GWT MVP my presenters typically have a lot of private members (event bus, rpc, message bundles created with GWT.create()...). We have been using a "ClientFactory" to generate views as singleton, so they won't be recreated each time we need them. That factory can also provides rpc, event bus, and other resources.

I can read in GWT doc that the main purpose of this factory is to gain access to object needed through your application. The second advantage of using a ClientFactory is that you can use it with GWT deferred binding to use different implementation classes based on user.agent or other properties.

My question is: if I don't and never will need different implementation of that factory with deferred binding, can't I just use a static classes & methods to retrieve my dependencies instead of a client factory or Gin ? I can't really grab the advantage of Gin over this solution, nor whether it could get me into trouble at some point / under some (not obvious) circumstances. I would usually avoid static classes in server-side code as it is multi-threaded but in client-side mono-threaded code I don't see where a problem could happen. Yet it seems most people use Gin or some other solution...

Answer 1

The problem with static is not about threading, it's about global state and singletons.

One of the main reason for using MVP in GWT is to be able to test your presenters without the need for GWTTestCase, because they wouldn't depend directly on GWT.create() or JSNI, both requiring a browser environment to run (note that GWT.create() is becoming usable in plain Java, and some projects such as gwt-mockito or gwt-test-utils use bytecode manipulation to make it run anyway). But even without MVP, that'd still be a problem:

Global states and singletons come in your way when testing:

• your tests are not isolated (they depend on global state, so two tests running at the same time share the same state and they're therefore not running in a controlled environment)
• you cannot use mocks/fakes/stubs or other test-doubles as the system-under-test directly uses singletons rather than depend on some objects passed by the environment (that one being different in tests and in production)

See http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/