GWT ClientFactory: Isn't this just a big blob/monolith?
anti-patterns, dependency-injection, gwt, java
Solution
The `ClientFactory` idea is just manual DI, to make for easy, comprehensible wiring. Without knowing anything about GIN, or even GWT, these applications appear to be mostly Java, letting you get the picture of how to make pieces work, without needing to learn the specifics of the author's preferred way to wire together an application.
Just like a sample Java tutorial would have you start with `public static void main(String[] args)`, or might have you build a completely manual Servlet, you can use this to get the idea, then move on to a better structured application. `ClientFactory`'s utility is from its simplicity and transparency as a concept, not because it is the One True Way to build a large application.
Problem
The GWT ClientFactory seems to be a budding new design pattern for GWT apps, and although is not officially a part of the GWT API, is encouraged by GWT and is found in countless GWT/MVP examples. I want to like the `ClientFactory` concept. But here's my concern: for really large apps, that have many screens, display regions and complex architectures, a single `ClientFactory` is going to become this massive monolith of a datastructure, with potentially hundreds of getter methods on it. So I ask: is this ok? Why is such a monolith design encouraged and acceptable for GWT but not in other (general) applications. More importantly, is there a way to decompose the broad-spanning `ClientFactory` into a hierarchy of factory objects, to help with code maintainability, dependencies/references, etc? If so, does one decompose a `ClientFactory` into smaller factories, each responsible for injecting a different part of the app with the necessary views, presenters, etc?