类计数指标的含义

Question

We are working on a bigger project with Ruby on Rails. As you might know, Rails works with MVC pattern and typically enforces the following class types for Domain objects:

• Controllers (+ Helpers)
• Models
• Views (eg erb)
• Serializers
• Mailers

We experienced - like many other teams - that this is not feasible for bigger, long-running projects.

So in our current project, we added some layers, so we typically have

• Controllers (+ Helpers)
• Policies (access control per controller)
• Presenters (aka ViewModel)
• Forms (containing all attributes available in an HTML form)
• Views
• Models
• Queries (static ActiveRecord queries)
• Serializers
• Mailers
• Services (Domain Service which extracts business code from controller)

It is much more testable, maintainable and understandable. However, our boss disagrees with "These are too many classes".

As he is typically a proficient architect (doing consulting), I don't want to simply reject this response. However, his time as active Java developer are gone and he often explains such sentences with his improved "gut feeling".

Of course, there are metrics that count classes - but is there a general approach to classify something like 'Classes per Domain object' or 'Class per Business case', which can be taken for an argument?

Answer 1

I have never heard of a rule or best practice which limits a number of classes per project, domain or whatever. One should create as many classes as he REALLY needs. The key word here is "REALLY" because quite often developers over complicate things and create unnecessary classes, layers or even tiers. Without the details about your project I suggest you do the following:

1. Ask your boss to elaborate on the "Too many classes" phrase. Ask for his concerns. If he is a good architect and a team member he understands his responsibility of coaching people.
2. Make sure you clearly explained to him why you needed those classes. Provide examples.
3. If your boss is stubborn, his best days as a developer are gone and he just wants to show his significance, remind him about his responsibility for a successful project. For example, tell him he is an architect and a person who makes the final decision and you will follow it because he is the one who is responsible for the project success but on the other hand it's your responsibility to be proactive and express any concerns you have to help your boss make the right decision. This should make your boss think again as he doesn't want to fail the project because of his "gut feeling".

Hope it helps!