Drink Remodeling Series [6]--Introducing Parameter objects

Briefly

If the method has more than 3 parameters, it will appear Shing when the method is called. When multiple parameters are encapsulated into an object, the calling method looks neat and tidy.
This is the refactoring strategy to be described in this article, "Introducing Parameter objects"--sealing the parameters of a method into a class and replacing the parameters of the method with the object of the class.

Introducing Parameter objects

Demonstrates this refactoring strategy, Orderserivce represents the order service, and the GetOrders () method obtains order information based on some criteria.
Before refactoring, the GetOrders () method looks like a lengthy, cumbersome invocation, and after refactoring, the GetOrders () method looks concise and only needs to pass in a parameter when called.

Advantages

This strategy seems to me to have at least two advantages:

1. You can reduce the number of parameters of the method and make the method more clean and tidy.
2. You do not need to modify the method signature when the method needs to append or delete parameters.

Watch out.

1. means that you want to add a new class to the project.
2. Instead of rigidly placing all parameters in one parameter object, it is necessary to determine that these parameters belong to a "common concept".
3. The method invocation parameter is reduced, and it is important to give the "parameter object" a good name.
4. During the project development phase, if the parameters of the method are subject to change at any time, it is recommended to design parameters directly as Object parameters.

For example: in a planar coordinate system, a circle is drawn based on coordinates and radii.

public void Createcircle (double x, double y, double radius) {    //Does work}

If we use parameter objects, we can express them in two ways.

Method 1: Encapsulate the coordinates as a parameter object
Method 2: Encapsulate the coordinate + radius as a Parameter object

These two approaches can be distinguished by using the appropriate parameter object naming.
Mode 1, refining the concept of "coordinates", so there is a point object, Mode 2, refining the concept of "circle", so use the Circle object as a parameter.

public class shapetool{    //Mode 1: Package coordinates public    void createcircle (point point, double radius)    {        //do Work
   }    ///Mode 1: Package coordinates + RADIUS public    void Createcircle (Circle circle)    {        //Does work    }}public class point{ Public    double X {get; set;}    Public double Y {get; set;}} public class circle{Public point point    {get; set;}    Public double Radius {get; set;}}

Example before refactoring

This code is for "Student enrollment courses".

public class registration{public    void Create (decimal amount, Student Student, ienumerable<course> courses, Decimal credits)    {        //do work    }}public class student{    }public class course{}

The Create () method looks difficult to understand, it has a large number of parameters, and does not have a good classification, we should encapsulate these parameters.

After refactoring

For the "Student enrollment Course" scenario, we refine a concept-"registration context", which can contain all the parameters of the above method.
After refactoring, the Create () method looks straightforward, the name "Registrationcontext" is just right, and all the parameters are placed in the Registrationcontext class.

public class registrationcontext{Public    decimal Amount {get; set;}    Public Student Student {get; set;}    Public ienumerable<course> Courses {get; set;}    Public decimal Credits {get; set;}} public class registration{public    void Create (Registrationcontext registrationcontext)    {        //does work    } }public class Student{}public class course{}

In some scenarios, when your method has a number of parameters that represent different meanings, it is difficult to extract a suitable noun from the names of these parameters.
For example: In order to put HttpRequest and HttpResponse into an object, it would appear chattering to name the object "Httprequestandresponse".
At this point, we can use a lazy approach, such an object named "XXX context."
For example, in ASP. HttpContext and ViewContext are such objects.

Drink Remodeling Series [6]--Introducing Parameter objects