Think of the view portion (Window) as a factory, whose job it is to instantiate the buttons and than wire them so that the call appropriate methods on the Controller class. This way your view has only one dependency, the controller. Yes, view becomes hard to test, but if all it does is forward the call to the controller there is nothing to test, really, so we focus on testing the controller.

I totally agree with your article, and apply these principles in my own code.

But in the case of GUI components, it can be hard to respect the point 2. Let imagine a “Window” class, containing a lot a “Button” objects. Pressing on some buttons calls a business service which executes SQL queries.

If buttons (which are the collaborators) are instantiated in the Window constructor, it becomes very hard to test. On the other hand, it becomes hardly maintainable if the Window constructor expects an arguments list of 50 buttons, instantiated by a DI container…

How would you proceed in this case ?

Thanks !

Singletons are a pattern, which people use. But just because it is a pattern does not make it good. Singleton is an anti-pattern.

I concur! This was especially obvious to me in Java World. Using globals is like saying Jehova to many Java programmers. But singletons are considered a ‘pattern’ and patterns are good.