Is a high atomicity in mvc overkill?

Question

As time passed by I learned that not strictly following the rules of a architectural pattern like mvc kind of counteracts the actual purpose of having a maintable software. Usually I end up with fat monster controllers or a model that does too much. Usually this happens because I didnt modularize my code enough just to avoid having too many classes.

In my very last project I tried a different approach: I analyzed what I wanted to program and tried to achieve a high atomicity by grouping the system into smaller components. These components will then each have a model, controller, and a view. Everything in top down strict hierarchical manner where each component is only dependent on its children and never the parent.

For example for a highly atomic archtitecture:

HumanModel, HumanController, HumanView
BrainModel, BrainController, BrainController
FrontalLobeModel, FrontalLobeController, FrontalLobeView,
NerveModel, NerveController, NerveView,
NerveNucleusModel, NerveNucleusController, NerveNucleusView
GolgiAparatusModel, GolgiAparatusController, GolgiAparatusView
etc

I could go on but you can probably see what I mean by now. While the amount of files or classes increases I believe it makes the application more "future proof". If I were to extend the functionality of the human then it would be easier and I dont have to rewrite anything. Since I use this approach I never had any problems. Even if some classes happen to be very minimalistic, in the future I might have to extend the functionality of the brain.

Why do people say its overkill?

Answer 1

Well lets take your intellectual example of the human brain:

HumanModel, HumanController, HumanView
BrainModel, BrainController, BrainController
FrontalLobeModel, FrontalLobeController, FrontalLobeView,
NerveModel, NerveController, NerveView,
NerveNucleusModel, NerveNucleusController, NerveNucleusView
GolgiAparatusModel, GolgiAparatusController, GolgiAparatusView

Your reasoning is sound to break up components into their subcomponents and not have cyclic dependencies.

If this is overkill, it would lie in the fact that perhaps you don't need a GolgiAparatusModel, a GolgiAparatusController, or a GolgiAparatusView. You may need one or two, but perhaps not all three.

A big part of having clear and concise code is simplicity, and simplicity means you don't create classes you don't need. I understand you want to future-proof your program, so you add these anyway. This may even be sensible if you are fairly sure you will be implementing these classes in the near future.

However, for the most part, determining how and where your project will evolve is somewhat unpredictable. The best thing you can hope for is look for trends in your code and provide a means to continue the trend in a straightforward way. For instance, if you persist your models to a database, it would make sense to give common interface from which all your models derive that would include common methods like save and update.

Though not even an interface should be used if there is no trend, as you create an interface with only one class that derives from it. This again is not making your program more simple, rather quite the opposite.

So my advice to you would be to create subcomponents as you've been doing, but only for classes that you require. It seems that you're onto something, and I certainly don't want to discourage that, but you should avoid whenever possible to create classes purely for "future-proofing" your code.