This question already has an answer here:
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?