How many methods can we reasonably put in an entity before it's considered bloated? [closed]

As 开发者_JAVA百科it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

With all those readings about single responsibility principle, decomposition, etc., it's difficult to get an idea of what should be the alarm signal that an entity gets bloated.

Is there some good advice/reading somewhere about how many methods we should consider a maximum, or if there are some objective other criteria?

---

In my opinion SOLID principles should be treated as guidelines, not as strict rules. SOLID violation is usually a reliable indicator of a design issue. But they are unavoidable sometimes.

There are quite a few code metrics. From NDepends:

NbMethods: (defined for application, assemblies, namespaces, types) The number of methods. A method can be an abstract, virtual or non-virtual method, a method declared in an interface, a constructor, a class constructor, a finalizer, a property/indexer getter or setter, an event adder or remover. Methods declared in third-party assemblies are not taken account.

Recommendations: Types where NbMethods > 20 might be hard to understand and maintain but there might be cases where it is relevant to have a high value for NbMethods. For example, the System.Windows.Forms.DataGridView third-party class has more than 1000 methods.

20 is what NDepends authors considered to be a reasonable threshold. Here is another opinion from objecteering:

This value should remain between 3 and 7. This would indicate that a class has operations, but not too many. A value greater than 7 may indicate the need for further object-oriented decomposition, or that the class does not have a coherent purpose. A value of 2 or less indicates that this is not truly a class, but merely a data construction.

As you can see these metrics are quite subjective. So you have to decide what makes sense for you and your team. From DDD perspective I found that using Value Objects is a very good approach to reduce SRP violations on Entities.