Are parameter objects required?

First, this articleArticleI wrote it on a temporary basis. I didn't give the article a general idea before, so the idea of the article may seem a bit messy. Even now I don't know when I want to end it.

 

This article is generated because I have read the "href =" http://www.cnblogs.com/yuyijq/archive/2011/04/26/2028789.html "> this article, in this article, the author gives a goodCodeThe reconstruction steps and how we need to refactor the code to improve the abstraction layer. However, he has always been questioning Martin Fowler's opinion on Parameter objects in refactoring. Don't rush against it, don't rush to reply, and continue to look down.

1. First think about functional languages like python and F #.

Let's first think about functional languages such as Python and F # (let's call Python a functional language for the time being). These functional languages, also, C # (starting from 4.0) has a concept called tuple. Let's take a look at how Python declares a tuple.

 

1 T = ( " Kym " , 22 , " Developer " )

 

I wonder if you are familiar with this code? Let's write a similar code in the article:

 

1 Private bool validate (string username, int age, string email)
2 {
3 // ... Validate
4 Return True;
5 }

 

Well, how can we call this method:

 

1 Public static void main (string [] ARGs)
2 {
3 Bool isvalid = Validate ( " Kym " , 22 , " Developer " );
4 If (Isvalid)
5 Console. writeline ( " Success " );
6 Else
7 Console. writeline ( " Failure " );
8 }

 

In fact, is the call of method parameters quite similar to that of tuple? Think about changing the method to this form:

1 Def Validate (userinfo ):
2 Bool nameisvalid = Userinfo [0] = ''
3 //   And So on
4 Return Isvalid

 

Then we can pass in the previous tuple:

 

1 If   _ Name __   =   ' _ Main __ ' :
2 Print Validate (t)

 

I believe that at this time, many people may know what concepts I want to express.

 

2. tuple and class

Yes. Actually, what I want to express is that the method parameter is essentially a tuple. So let's look at the difference between tuple and class?

In terms of syntax classification, tuple is called a sequence, and the list is divided into the same category. The class, even in the case of weak object-oriented objects (let's call it this for the time being). For JavaScript, it is also very different from dictionary and hashtable into the same class.

A tuple. If we do not consider the meaning of thinking, we can replace it with list.

T = ('kym', 22, 'developer') and L = ['kym', 22, 'developer'] are no different in usage. Similarly, we can encapsulate it into a user object:

 

1 Class User (object ):
2 Def   _ Init __ (Name, age, work ):
3 Self. Name = Name
4 Self. Age = Age
5 Self. Work = Work

 

However, in terms of thinking, these are completely different:

In fact, a strong type language such as C # is more obvious. List <t> can only be used to accommodate elements of the same type. In other words, list <t> can only be used to hold elements of the same meaning. We can call it a sibling element.

The difference between tuple and class depends on the relationship between elements. Let's think about the single responsibility principle (SRP). There should be only one reason for change in a class, that is, only when these elements are highly cohesive can we put them together. In contrast, tuple is a weaker cohesion.

 

3. Need to refactor

After reading the above content, let's think about whether to refactor it. Or whether or not the parameter object depends on what?

First, we should treat method parameters as method parameters rather than tuple. That is to say, we should convert the problem of reconstruction to tuple or class.

The value of tuple or class depends not on the number of parameters, but on the cohesion between parameters.

 

4. Some small extensions

I believe many people have seen such code:

 

1 Public   Void Insert ( String Username, String Password, Bool Isvalid)
2 {
3 // Verification required?
4 If (Isvalid)
5 {
6 Bool Usernamevalid = Username ! =   '' ;
7 Bool Passwordvalid = Isstrongpassword (password );
8 If (Usernamevalid && Passwordvalid)
9 {
10 This . Storedomaindatabase (username, password );
11 }
12 }
13 Else
14 {
15 This . Storedomaindatabase (username, password );
16 }
17 }

 

first, whether this parameter is too long. If you think it is not long enough, what address should you set, job and so on! Long enough! But should we encapsulate these parameters into a parameter object? If yes? So how to write this class?

 

1 Class Userargsforvalidation
2 {
3 String Username;
4 String Password;
5 Bool Isvalid;
6 }

 

Is this really object-oriented? Obviously not. But what is the problem? Is the excessive abuse of method overload.

If I remember correctly, Martin Fowler mentioned this in his book. If a condition selection statement, such as if or switch, is displayed in the method, let's split this method into two methods: insertwithvalid (string username, string password) and insertwithoutvalid (string username, string password.

Therefore, in most cases, if a method carries many parameters, these parameters must have a relatively high cohesion, for example, let's first think about whether to use other refactoring principles. If not, think about tuple or class, instead of four parameters, and eight.

In fact, there is a good distinction principle. Remember to say in the circle of design patterns that if the class name you design carries the name of this pattern, such as productfactory, accessadapter, then you abuse the design pattern. Of course, this statement is somewhat extreme. However, we may also try to migrate this principle to method refactoring. If your class name contains parameters such as ARGs, then you are also an abuse of refactoring.