Does increasing the number of classes increase code complexity? [duplicate]

Question

This question already has answers here:

How do you balance out code structuring (few big functions vs. many small ones)? (3 answers)

Closed 7 years ago.

To illustrate the question, let's say we have two programmers of comparable skill that both solve the same problem. The code they turn out has roughly the same lines of code, but one programmer uses 5 classes while another programmer uses 20.

Both sets of code get comparable wtfs per minute in code review, implying that the code is not hard to follow and doesn't do anything silly.

Is the code with 20 classes more complex than the code that utilizes 5?

Answer 1

Cohesion and Coupling are the two relevant terms, however, there is no possible fixed answer due to their contradicting nature.

Cohesion

Cohesion is a measure of how closely together the methods of a class are working. If you have high cohesion, then most of your methods are responsible for a similar thing, whereas if you have low cohesion, the methods are doing more or less independent things. This is slightly related to the Single Responsibility Principle (SRP), which tells us that you should aim for high cohesion.

Coupling

In contrast to cohesion, coupling refers to interdependencies between modules/classes. If you have high coupling, this means that your modules interact a lot with each other, whereas low coupling means that there are only few interactions, i.e. small interfaces. Again, it is easy to see that low coupling is better.

Contradiction

The problem with achieving both, high cohesion and low coupling, is that changing your code to improve one means that you reduce the other.

As a simple example, consider all of your functionality to be contained in one single class. This means you have extremely low coupling, which is good! But of course, you also have extremly low cohesion, because all of your class's methods will have to do different things.

On the other extreme consider splitting things up into soooo many classes, that each of them only contains a single small method. That means you have very high cohesion, which is good again, but to do the actual work, these methods would have to access a lot of other classes. These dependencies mean you get very high coupling as well, which is not good either.

Tradeoff

Essentially, you end up with a tradeoff: Focus on cohesion, and you lose out on coupling. Focus on coupling, and you lose out on cohesion. To make a good choice about where you should go on that tradeoff scale, coupling and cohesion themselves are insufficient criteria. Instead you should look to other criteria of code quality, and see where on the scale they lead you.

For example, the SRP gives you good cohesion, and there are people out there who advocate this as the only truth, but of course if you follow the SRP very strictly, you end up with lots of classes and high coupling. Sometimes, you may find that all of that coupling is giving you lots of trouble. In such a case you may justify that it's worth to reduce the coupling at the cost of cohesion by violating the SRP (or let's just say re-interpreting what that single reponsiblity is).

As a best practice approach, I believe that the SRP is a save bet. In general, high coupling is more problematic than low cohesion, simply because we find it easier to deal with a problem localized to one class (cohesion). Therefore, if you follow the SRP it'll lead you towards the low coupling end of the tradeoff scale, which is at the very least a good point to start from.

Answer 2

I generally have one class for each of my tables, plus as many enums as necessary for enumerated fields, plus data services and user controls and all kinds of stuff. The only WTFs I get are from users, although the rate is measured in hours, not in minutes.

Since there's no discussion of language specifics, I can only go by what I do in C#. I generally try to create highly repeatable design patterns, so that someone looking at one class will pretty much find something similar in the other ones. I'm not sure how I could 'cut down the number' given my design rules.