3

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?

  • 1
    "Why do people say its overkill?" Because they are dumb, blind or both? – Timothy Truckle Jan 11 '18 at 11:30
  • 1
    We cannot tell you why other people say things. Why do you ask random people on the internet, when you could ask those people that actually say it? They probably have more information than we do. – nvoigt Jan 11 '18 at 11:44
  • In C# when you have highly modular code that leads to a lot classes which, in turn, tends to create a lot of files. I've spoken to a few developers from different fields (ie, not business software) who were uncomfortable with this. To them lots of files = lots of wasted time looking for that bit of code you want. However, when I explain that there are techniques to help with this (eg, project structure, explicit naming) they seem to relax a bit. I guess what I'm saying is that unfamiliarity can lead to seemingly odd behaviour. Given enough context people tend to agree with one another. – MetaFight Jan 11 '18 at 13:41
4

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.

  • In accordance to this answer I would like to add that a good approach is to have this component structure somewhere scetched as a guideline, but only implement those parts which are really needed now, for the current version of the program. So in version 1 of the software, let us assume there is not more required than the "Human" and "Brain" parts, then better not implement any of the FrontalLobe<XYZ> classes, not even "empty". That would not make the application more "future proof", quite the oppsite. – Doc Brown Jan 11 '18 at 11:59
  • 1
    ... and this principle has a name, it is called YAGNI. – Doc Brown Jan 11 '18 at 12:00
  • @DocBrown what if frontal lobe is not empty but very minimalistic (as in nearly empty) but im sure that in future versions i will need to extend the lobe functionality. Is there a reason to avoid having a frontal lobe class only because its very minimalistic? – Asperger Jan 12 '18 at 15:30
  • @Asperger: this is a trade-off, as always, use your common sense. If you have a modern IDE like Visual Studio or Eclipse, handling multiple files is not much of an issue. However, when you can save a whole class by keeping 1 line of code in a file where it normally shouldn't be, you should probably be pragmatic and let it there (maybe with a comment - "Move this from FooController to BarController in case it gets extended") – Doc Brown Jan 12 '18 at 16:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.