In the amazing The Philosophy of Software Design, John Ousterhout argues that having large classes that implement the full expected behaviour can be better than smaller classes that have to get together to do the same. He calls the idea of creating too many small classes, "classitis".
True, but I understand the concept of deep modules differently, specially based on the language.
One way I see it is that when we are using a class, we often like a fluent intercafe where I can reach every thing related to a concept from a single point.
Using languages such as ruby and php we can achieve that through modules and traits, respectively.
I'm not saying that a class should have hundreds of methods using these mixin techniques, but that a class could have many related enter point for behavior.
Take a ORM for active record implementation as an example. From a single class I can fluently compose a complex query using a mixture of composition and mixins.
True, but I understand the concept of deep modules differently, specially based on the language.
One way I see it is that when we are using a class, we often like a fluent intercafe where I can reach every thing related to a concept from a single point.
Using languages such as ruby and php we can achieve that through modules and traits, respectively.
I'm not saying that a class should have hundreds of methods using these mixin techniques, but that a class could have many related enter point for behavior.
Take a ORM for active record implementation as an example. From a single class I can fluently compose a complex query using a mixture of composition and mixins.