Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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?

share|improve this question

marked as duplicate by gnat, MainMa, BЈовић, MichaelT, Kilian Foth Jul 31 '13 at 10:50

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2  
3  
Since the only correct metric is the number of WTFs per minute, you already have your answer. –  MainMa Jul 31 '13 at 4:47
    
too many classes is a problem but too less classes is also a problem. so it depends on how many classes are really required –  Bryan Chen Jul 31 '13 at 4:49
    
@gnat Ah, thank you. Cohesion is exactly the term I need for describing this question. –  mortalapeman Jul 31 '13 at 4:58
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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