You’ll often see a two or three thousand line Controller class, and there are several reasons why the class has grown so large:

  • Too many long functions
  • The class contains an extraordinary number of fields and functions

Quantitative change causes qualitative change, and maybe each function is very short, but there are too many of them

Modularity of applications

Have you ever wondered why you wouldn’t put All Code in a file? Because your subconscious knows:

  • The same function module cannot be reused
  • The complexity is beyond personal comprehension

One person’s understanding of things is limited, in the domestic Internet agile development environment, no one can be familiar with all the code details.

The most effective solution to complexity is to divide and conquer. Therefore, each programming language has its own modularity scheme:

  • Partition by file from the original
  • Later, OO was used to classify by class

Developers are no longer faced with details, but modules, the number of modules is obviously far less than the number of details, the cost of understanding is greatly reduced, development efficiency is also improved, no longer 996, can talk to the girl more every day.

Modularity is essentially the decomposition of a problem because of a person’s limited ability to understand it.

Say so much I understand, that exactly how to break the big categories into small categories?

How do 2 categories come from?

2.1 Responsibilities are not single

The most likely cause of large categories.

CR a code:

This class holds the typical characteristics of a large class and contains a bunch of fields: are all of these fields indispensable?

  • The userId, name, and nickname should be the basic information of a user
  • Email and phoneNumber are also associated with users

Many apps provide a way to log in using your email or phone number, so it makes sense to put this information here

  • AuthorType: indicates whether the author is a signed author or a common author. The signed author can set the payment information of the work, but the common author does not have this permission
  • AuthorReviewStatus, authorReviewStatus, the author to become a signed author, need to have a process of application review, the status field is the review status
  • EditorType, editorType, editor can be editor, editor can be small, different permissions

This is not all of the User class. But just looking at this shows the problem:

  • The average user is neither an author nor an editor

Author and editor of these related fields, the average user meaningless

  • For users who become authors, the edited information means little

Because authors can’t be editors. The editor does not become the author, and the author information is meaningless to the user who becomes the editor

There will always be information that is meaningless to some people but necessary to others. The crux of the problem is that there is only “one” user class.

Ordinary user, author, editor, three different roles, from different sides of the business, care about different content. Simply because they are all users of the same system, putting them in the same user class causes the class to be repeatedly modified by any change in the needs of the business side, which is a serious violation of the single responsibility principle. So the key is to split responsibilities.

Although this is a class, it becomes bloated by putting together all the things that different characters care about.

Just split the different pieces of information:

public class User {
  private long userId;
  private String name;
  private String nickname;
  private String email;
  privateString phoneNumber; . }public class Author {
  private long userId;
  private AuthorType authorType;
  privateReviewStatus authorReviewStatus; . }public class Editor {
  private long userId;
  privateEditorType editorType; . }Copy the code

Unpack the Author and Editor classes and move the fields related to Author and Editor into each class. Each of these classes has a userId field that associates the role with a specific user.

2.2 Fields are not grouped

Sometimes it feels like some fields really do belong to a class, and as a result, the class is still big.

The new User class was previously split:

public class User {
  private long userId;
  private String name;
  private String nickname;
  private String email;
  privateString phoneNumber; . }Copy the code

These fields should all be part of the user’s information. But it’s still not a small class, because the fields in this class don’t belong to the same type of information. For example, userId, name, and nickname are the basic user information, and email and phoneNumber are the contact information of the user.

From the perspective of requirements, basic information is the kind of content that will not change once it is determined, while contact information can be adjusted according to the actual situation, such as binding various social accounts. Put all this information into a class, and the class stability is pretty low.

Accordingly, the fields of the User class can be grouped:

public class User {
  private long userId;
  private String name;
  private String nickname;
  privateContact contact; . }public class Contact {
  private String email;
  privateString phoneNumber; . }Copy the code

Introduce a Contact class, put email and phoneNumber in it, and any subsequent changes to Contact information can be put in this class. This time, different information is recombined, but each class is smaller than before.

What’s the difference between the two splits?

  • The first is to separate entities according to their responsibilities
  • After that, the fields are grouped and different information is encapsulated by classes

The breakdown of large categories into small categories is essentially a design exercise based on the principle of single responsibility design.

If we break down the big categories into smaller categories, the number of categories will increase, so will the cost of understanding be increased? This is an excuse for many people not to break it down into big categories.

All programming languages have built-in mechanisms such as packages, namespaces, and so on to group classes together. When you don’t need to expand in detail, you are faced with a collection of classes. And then there are all kinds of libraries that take all of this stuff and package it up a little bit further, so that we’re dealing with simple interfaces, and we don’t have to worry about the details.

Software is being built in this way.