Too many CS files in a single project [duplicate]

Question

This question already has answers here:

Single Responsibility Principle - How Can I Avoid Code Fragmentation? (7 answers)

Closed 6 years ago.

I am working on a ‘brown-field’ project, with a team of programmers. I understand each programmer will have different styles. I am running into some criticism with my coding style, specifically creating ‘too many class files' (aka too many CS Files, not number of classes).

I have always tried to separate project/business logic into smaller and smaller chunks contained within separate pages (when it is possible).
As an example, a ‘green-field’ project, dealing with an ‘Account’ I might have 5 CS pages (Model, Views, Custom Mappers, Controllers, Presenters, Services…).

The current project has about 40-45 domain specific entities, which means I might have up to 200 CS when the project is all completed.
Of course each would be well separated into an understandable structure.

I was also taught/told that CS files are cheap and don’t worry about the count number of files created as long as it make sense to someone else looking at the code-base.

After the criticism I received, I decided to bend and follow the past code base structures.
As I did this, I can across several CS files, most of which extended beyond 1000 lines of code, and some over 4500 lines of code.

I am having a hard time trying to explain my point of view, which is mainly based on readability and maintainability down the road.

How to explain my point of view to the team OR rather demonstrate the need to follow Single Responsibility principle?

Answer 1

In my experience, the argument against "too many class files" is always perpetuated by people who simply aren't disciplined enough to separate responsibilities well. Your experience of finding 4500+-line code files is exactly the same experience I have with these teams. Files will tend to grow, so it's a good practice to start them small anyway.

A common counter-argument I hear is that it's "confusing to debug" code that is passed on from one class to another, etc., but in reality, you shouldn't care about all the implementation details of all the classes involved in a flow, so you shouldn't need to step through all of them in the first place. Further, if you have proper unit tests set up, you shouldn't need to be stepping through the code incredibly often.

Speaking of unit testing, having many separate classes makes your code much more testable, and that is a good thing. I am willing to bet that the test coverage on this current project is all but non-existent, since unit testing would reveal the problems with the architecture of this codebase right away.

It sounds like you're in the unfortunate situation of being in a somewhat toxic environment in which popular opinion trumps reason, and it can be frustrating to be the only reasonable voice in a group, but don't stop fighting the good fight. Point them to resources by professionals, like Robert Martin or Martin Fowler. It's likely that your team is so rooted in their ways and tied to their ego that they won't budge, but don't stop pushing them in the right direction.

If by some miracle you have an existing unit test solution set up for your project, you might want to try the passive-aggressive introduction of unit-tests-as-guards against bad code that your team may be writing. On a toxic team I worked on, I found it helpful to refactor code into testable chunks and write unit tests around it, guaranteeing that my coworkers would face pain if they ever tried to change things for the worse. (Of course, this might just lead them to the conclusion that "unit testing is bad!" so try at your own risk. ;) )

Answer 2

It's hard to say if you're gone too far without seeing more concrete examples, but keep in mind that in one of Bob Martin's treatments of the SRP, he states:

If [...] the application is not changing in ways that cause the two responsibilities to change at different times, then there is no need to separate them. Indeed, separating them would smell of Needless Complexity.

There are of course many reasons to create separate classes besides following the SRP, e.g. reducing coupling, increasing cohesion, separation of concerns, etc; however it's helpful to question yourself as to whether you're actually realizing benefits because of a given design decision.