I don't consider this so much "WTFy".
When deciding whether a design a good or bad I'd say use these criteria:
1. Does it require lots of redundant code/boilerplate? (This is a problem because it slows down development)
2. Would a single change in the requirements require lots of changes in many different places? (This is a problem because one may forget to change one of these places when implementing such a change)
3. Is there a risk a future developer misuses the design and thereby creates bugs?
4. Is it a well-known pattern? (If not, it is a problem because new developers have to learn the pattern first)
Now let's analyse this design.
1. The redundant code is the app passed to every single application element constructor, and the fact that all dao accesses need to be written app.dao instead of just dao. I'd say this is pretty minor. Note that using a singleton pattern "Application.getInstance().getDao()"is not that much shorter especially as you now need to write the implementation of getDao().
2. Not really. You want to change the dao implementation by another one? Only modify Application. You find out MyFrame has another dependency (in addition to dao)? Just access it through application - no need to modify Application or whatever code instanciates MyFrame.
3. There are two risks here: first Application.dao is writable, so a developer might be tempted to *modify* Application.dao from another place (which is the reason people say globals are "bad" - because they can be modified from a method without the method signature making this evident). This could be avoided by marking dao as final in application, and adding an Application constructor to pass custom dao implementations (for use from e.g. unit tests). Second risk: there's a Singleton pattern at use here (people assume there's only one application instance so that everytime someone writes app.dao they access the dao of the same app, and therefore the same dao as well), BUT people might be tempted to pass a new Application instance. Solution: mark Application's constructors as private (or maybe package private), [OR mark dependencies (dao and others) as static - in that case you no longer need to pass the application instance. This second solution is less good because it prevents you from making unit tests with different dao implementations AND still having dao marked final.]
4. This is not the most usual way of doing dependency injection, which is probably why the first reaction is WTF. But it doesn't IMO have issues itself.
(Using a dao directly instead of having a service layer is another issue that I did not cover above. That MAY be a problem if data has/may have in future integrity/consistency requirements that would need to be implemented in a service, but it is orthogonal to my analysis above - nothing would prevent Application having a public Service attribute, and have the Service itself use a Dao).
(PS I accessed this account through bugmenot - treat this as slashdot's anonymous coward ; I did not write or even read any of Strolskon's other posts)
You can guess my password.