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.

About the 9th “rule” (Mixing Service Objects with Value Objects)… i agree that this might make the code harder to test, but completely separating the two clearly breaks the OO principle of keeping together data and logic.

Separating data and logic brings to breaking encapsulation.

I have seen a lot of project following blindly this separation philosophy and ending up in writing procedural code under the mask of oo.

And this concern is at the heart of a whole philosophy, domain driven design.

What do you think about it ?