Refactoring Notes-Refining classes

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

The Move field is described in the previous article . This paper introduces the reconstruction technique of "refining class".

Let's learn this refactoring technique.

straight to

Discovery: A class has done something that should be done by two classes.

Workaround: Create a new class to move related fields and functions from the old class to the new class.

Motive

We have more or less heard the teachings that a class should be a clear abstraction, dealing with some clear responsibilities. However, in actual work, the class grows and expands. You'll add some functionality here and add some data there. When adding a new responsibility to a class, it is not worth having a separate class for this responsibility. As responsibility grows, the class becomes overly complex. Soon, the class becomes mess, and then you don't want to manage it.
Such classes tend to contain a large number of functions and data, which are often too large and difficult to understand. At this point, you need to consider which parts can be detached and separate them into a single class. If some of the data and some functions always appear together, some of the data will often change and even depend on each other, which means that it should be separated from processing. A more useful test is to ask yourself: what happens if you move some fields and functions? Will other fields and functions become meaningless?
Another notable area is the subclass of the class. If it is found that subclasses affect only some of the attributes of a class, or if it is found that some attributes need to be subclass in one way, while others need to be subclasses in another way, it means that the original class needs to be decomposed.

Practices
(1) Decide how to decompose the responsibilities of the class.  (2) Create a new class to represent the responsibilities separated from the old class (The old class is renamed if the remaining responsibilities of the old class do not match the old class name).
(3) Establish a connection relationship from the old class to access the new class. (You may need a two-way connection, but do not create a "new class to old class" connection until you really need it)
(4) For each field to be moved, use the "move field" to relocate it.
(5) After each move, compile and test.
(6) Move the necessary functions to the new class using the "removal method". Move the lower-level function (the function called "redundant calls to other functions" by other functions), and move the upper function.
(7) After each move, compile and test.
(8) Check and streamline the interface for each class. (If you set up a two-way connection, check if it should be changed to one-way connections)
(9) Decide whether to expose the new class, and if it is determined to expose it, decide if it should be a reference object or an immutable object.



Example
we are from a simple person classStart:

Refinement class Person {private string _name;private string _officeareacode;private string _officenumber;public string Get_na Me () {return _name;} Public String Gettelephonenumber () {return ("(" + _officeareacode + ")" + _officenumber);} Public String Get_officeareacode () {return _officeareacode;} public void Set_officeareacode (String areacode) {_officeareacode = AreaCode;} Public String Get_officenumber () {return _officenumber;} public void Set_officenumber (String number) {_officenumber = number;}}

In This example, you can separate the behavior associated with a phone number into a separate class. You first need to define a telephonenumber class to represent the concept of "phone number":

Class Telephonenumber {}

then establish a connection from person to telephonenumber:

Class Person {//...private telephonenumber _officetelephone = new telephonenumber ();}

     You can now move a field by using the Shift field technique:

Class Telephonenumber {private string _areacode;public string Get_areacode () {return _areacode;} public void Set_areacode (String areacode) {_areacode = AreaCode;}} Class Person {//......private telephonenumber _officetelephone = new telephonenumber ();p ublic String Gettelephonenumber () {return ("(" + get_officeareacode () + ")" + _officenumber);} Public String Get_officeareacode () {return _officetelephone.get_areacode ();} public void Set_officeareacode (String areacode) {_officetelephone.set_areacode (AreaCode);}}

You can then move the other fields and use the Move function method to shift the related functions into the Telephonenumber class:

Class Person {//......private telephonenumber _officetelephone = new telephonenumber ();p rivate String _name;public String get_name () {return _name;} Public String Gettelephonenumber () {return _officetelephone.gettelephonenumber ();} Public telephonenumber Getofficetelephone () {return _officetelephone;}} Class Telephonenumber {private string _areacode;private string _number;public string Get_areacode () {return _areacode;} Public String Gettelephonenumber () {return ("(" + _AreaCode + ")" + _number);} public void Set_areacode (String areacode) {_areacode = AreaCode;} Public String GetNumber () {return _number;} public void Setnumber (String number) {_number = number;}}

the next step is to decide whether to expose this new class to users. You can delegate a phone number-related function in person to telephonenumber to completely hide the new class, or you can expose it directly to the user. It can also be exposed to a subset of users (users in the same package) and not to other users.


This paper mainly introduces the reconstruction technique--refining class. This refactoring technique will also be used frequently in the development process, think of the development process, some of the characteristics of a class moved to another new class, their responsibilities are clearly divided, so it is also easy to develop later maintenance. Refinement classes are a common technique for improving concurrent programs. Because it makes the two classes that are refined can be locked separately. However, if you do not need to lock two objects together, you do not have to do so. There is also a problem with the transaction, when it is ensured that two objects are locked at the same time. There is also a certain danger. Finally, I hope this article will be of some help to you. There are questions to leave a message, thank you. (PS: Next article will introduce refactoring notes--inline the Class)

Refactoring Note Articles

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 fieldsRefactoring Notes-Refining classes

Refactoring Notes-Refining classes