When there are more than three parameters, they are usually encapsulated in a class to form a parameter class. Parameter classes are usually the communication link between classes or methods, serving as a link between the preceding and the following.

Basically, a project of a slightly larger scale will be composed of multiple modules, and these modules will be divided into multiple levels, such as Controller, Service, DAO, etc. If a parameter class is passed like a pin, across multiple modules and levels, the result will be deeper and deeper holes. These pits will be described in detail.

For example, A project consists of modules A, B, and C. Module A receives HTTP requests and acts as A gateway. Module B provides specific business processing services; The C module provides the basic CRUD operations. A calls B, and B calls C, completing the request-to-response process. At this point, if a parameter class is designed to receive the parameters of HTTP requests, the parameter class is directly passed to B when the service method in module B is called. Unfortunately, B calls the service method in C, and the parameter is directly passed to C. See here probably some people will say no! I think so too, but it’s true. If the requirements are changed, one parameter name needs to be changed, which will lead to the change of one part and all the modules used need to be changed, and then the corresponding modules need to be re-tested, which is laborious.

If you define A parameter class for each module within its own scope, there will not be so much trouble, A module you change your, B, C modules can be determined according to the situation, do not change!

This design is a counterexample of low coupling, which is too much in series, resulting in too much coupling!

The above mentioned structural bloat is actually a design error. When it comes to interface programming, it is necessary to design an interface with a single responsibility. In my opinion, this interface is not only interface, but all places with communication, such as interface, class and method. Piling parameters for multiple purposes into one class clearly violates this design principle.

There are two reasons for this pass-through approach:

One is the lack of experience in coding just entered the line;

Two is years of experience veteran, in order to achieve code reuse and simple principle, write less code to achieve a powerful “general”.

When it comes to GM, you don’t have to! If you have two classes that have most of the same properties, you can use Dozer to convert them. It’s easy to use, and in most cases you can convert them between classes without too much configuration.

The bottom line is don’t design or use a parameter class that goes all the way. Achieve high cohesion and low coupling, single responsibility, avenue to Jane!