Refactoring notes-moving fields

This article is in the study summary, welcome reprint but please specify Source: http://blog.csdn.net/pistolove/article/details/42780243

the "Move function " is described in the previous article . This paper introduces the refactoring technique of "moving field".

Let's learn this refactoring technique.

straight to

Discovery: A field in a program is used more frequently by a class other than its resident class.

Workaround: Create a new field in the target class, modify all users of the original field, and make them use the new field instead.

Motive

Moving state and behavior between classes is an essential step in the refactoring process. As software development progresses, you will find that new classes are needed and that you need to drag existing work responsibilities into new classes. In this week's seemingly reasonable and correct design, the next week may no longer be correct. It's certainly not a problem, but if you've never had it, that's a problem.

If you find that a field has more functions using it in another class than its resident class, you should consider moving the field. The so-called "use" may be done indirectly by setting a value/accessor function. The user (function) that moves the field may also be involved, depending on whether the interface needs to remain unchanged. If these functions appear to fit in place, select the Move field.

You may also need to move the fields when using the refinement function. You will then choose to move the field first and then move the function.

Practices
(1) If the access level of the field is public, it is encapsulated. (2) compile, test. (3) Establish the same field as the original field in the target class, and establish the corresponding value/accessor function at the same time. (4) Compile the target class. (5) determines how the target object is referenced in the original object. (6) Delete the original field. (7) Replace all references to the original field with a call to a target function. (8) compile, test.


Example
We are still the account class in a previous postStart:

Class Account {Private AccountType _type;private double _interestrate;double interestforamount_days (double amount, int Days) {return _interestrate * amount * days/365;}}

I want to move the _interestrate of interest rates to the AccountType class. There are currently some functions referencing it, and interestforamount_days () is one of them. The next step is to establish the _interestrate field in AccountType and the corresponding access function:

Class AccountType {private double _interestrate;void setinterestrate (double rate) {_interestrate = rate;} Double Getinterestrate () {return _interestrate;}}

This is the time to compile the new AccountType class. Now you need to use the Accouttype object for the function that accesses the _interestrate field in the account class, and then delete the _interestrate field in the account class. At this point, the original field must be deleted to ensure that its access function does alter the operand, because the compiler will help us.

Class Account {private AccountType _type;double interestforamount_days (double amount, int. days) {return _ Type.getinterestrate () * amount * days/365;}}

using self-encapsulation
If you have a lot of functions that use the _interestrate field, you should first use self-encapsulation:

Self-encapsulated class Account {private AccountType _type;private double _interestrate;double interestforamount_days (double amount, int days) {return getinterestrate () * amount * days/365;} void Setinterestrate (double rate) {_interestrate = rate;} Double Getinterestrate () {return _interestrate;}}

       this way, after moving the field, you only need to modify the Access function:

Class Account {private AccountType _type;double interestforamount_days (double amount, int. days) {return getinterestrate ( ) * Amount * days/365;} void Setinterestrate (double rate) {_type.setinterestrate (rate);} Double Getinterestrate () {return _type.getinterestrate ();}}

       in future development, if necessary, I can modify the access functions of the user, let them use the new object. Using self-encapsulation makes it easier to move functions to the target class using the Remove function. If the Move function references a field's access function, those reference points do not have to be modified.



This paper mainly introduces the reconstruction technique--moving field. As the development progresses and the number of classes is increasing, you may find that the fields that are first placed in a class have more communication with the later classes, so that we should move the field to more classes that use it. Finally, I hope this article will be of some help to you. There are questions to leave a message, thank you. (PS: The next article will introduce refactoring notes--refining Class)

The refactoring Note article is as follows

Refactoring Notes-Introductory article

Refactoring notes-bad taste of code (UP)

Refactoring notes-bad taste of code (bottom)

Refactoring notes-building a test body

Refactoring notes-Refining functions

Refactoring notes-inline functions

Refactoring notes-Inline temporary variables

Refactoring notes-replacing temporary variables with queries

Refactoring notes-Introduction of explanatory variables

Refactoring notes-breaking temporary variables

Refactoring notes-Removing the assignment of parametersRefactoring notes--moving functions
Refactoring notes-moving fields

Refactoring notes-moving fields