Deep vs. Shallow modules

The other day I heard one of the founding developers at the company I work for talking about deep and shallow modules. I asked what it was and got a pretty basic explanation which I wasn't happy with so I started researching this a little bit.   

A deep module is a module with a small interface hiding a big functionality beneath.

Okay, nice, that I can agree with, that just seems to be another way to say use abstractions. What I take issue with is that after some more research I stumbled upon a few posts which basically says that deep modules should have lots of functionality hidden behind their interfaces and of course some java bashing (which I'm happy to jump on at times, but not today).

Another word that comes up during my research is calssitis, which seems to mean to many small classes. What I'm sensing is a critique against having small tight classes and that these persons who are promoting deep modules also want to keep a lot of the functionality within the class.

Okay so fewer bigger classes and smaller more specialized interfaces seems to be what the deep-module folks want. I don't, before I explain why I want to list some of the reasons why I think that they want this.

  1. Bad naming, this is kind of self explanatory, but when we name things badly the cognitive load on the next developer will increase because the name doesn't help, rather it confuses. Think; "why is payment-handler sending emails at scheduled intervals?".
  2. Low cohesion, high coupling. The code will naturally degrade over time, as people rotate, someone who's new will want to implement the functionality they've been tasked with and not take too much time. I've never been at a place where this hasn't happened. With time this means that the class that was initially a shining example of well design OO-code became a spaghetti-monster.
  3. InterfaceNameImpl or whatever pattern is in your language (I'm mostly working in java), it's hard to argue for why you'd need to create an interface-file for something that will only ever have one implementation but still people do it, and then they call it a pattern, I'd rather call it an M.O.
  4. How much context you can handle, this is the only reason that I think is based more on how people are rather than sloppiness or cargo-culting. I believe some people can handle a single file much easier and jumping around a few thousand lines of code without problem. I myself get lost in that, I'd much rather have a small class that I trust and then forget about it.

Okay so lets begin with interfaces, sure they are a nuisance at times because they cause a layer of navigation in java (not necessarily abstraction - especially shallow interfaces) but then again every public method is a part of the class interface, but they're an important part in polymorphism. The thing we should focus on is reducing the amount of bloat, remove java interfaces that only have one implementation and remove "Impl" from the name in the implementation.

If classes are kept small and pruned regularly then they will keep a high cohesion and probably a low coupling as well.

Take time naming your classes, and don't be afraid to rename them either, naming is hard.