9

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?

7
  • 1
    The only hope for your question is to show some examples in code, so that we can evaluate them.
    – Robert Harvey
    Commented Mar 18, 2014 at 16:25
  • Are you got critiscm because of too many class files, or because of too many classes?
    – Doc Brown
    Commented Mar 18, 2014 at 16:37
  • @DocBrown: What's the difference? Most modern OOP languages advocate one file per class, and if there are multiple files per class, I doubt that the number of files is the problem.
    – Robert Harvey
    Commented Mar 18, 2014 at 16:38
  • @RobertHarvey: well, as you already know in C# there is no need to map 1 class to 1 CS file (you can have multiple classes in one file, or partial classes distributed over many files). And I noted that the OP did not write "classes", he wrote CS files in his question. So does he distribute any class about a Model CS file, View CS file, Custom Mappers CS file, Controller CS file, etc., just to be uniform in his structure? Are is there a reasonable separation of concerns, in this structure? I think we need not only code examples to see, but also his physical code distribution explained.
    – Doc Brown
    Commented Mar 18, 2014 at 16:47
  • 3
    Questions framed like 'how do I explain...' are really asking 'how do I make them agree...'. Thats a workplace issue, not a programming one. It may be they understand quite well and simply have reached a different conclusion than you have.
    – GrandmasterB
    Commented Mar 18, 2014 at 17:10

2 Answers 2

Reset to default
8

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. ;) )

9

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.

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