"Refactoring – Improving the design of existing code" reading notes----Extract Class

In object-oriented, we should have a clear sense of responsibility for the concept of classes, that is, each class should have only one point of change, and each class should only be subject to a single factor, that is, each class should have only one clear responsibility. Of course, when it's easier said than done, a lot of people may be like me, the first time to build a class of confidence, remember the SRP principle, but as the development progress continues, it is likely that you will give you the original design of the class to add new fields or add new functions, for a small increase you may cause trouble, Consider not going to do a new class alone to decompose. Over time, your class will become more and more bloated, with more and more responsibilities in charge. Such classes often have a lot of data and functions that are often too large to understand. At this point you should consider what can be separated out as a separate class. If you find that some of the data and some functions always appear together, and some of the data often changes at the same time or even each other , it means that you should separate them. Of course, the author also mentions a better technique, you ask yourself, if you move some functions and fields individually, what happens, and whether other functions and fields become meaningless.

Another situation is often in the late development of the class to do the sub-class problem. If you find that a subclass affects only some of the attributes of a class, or if you find that some attributes require a subclass, some attributes require a different subclass, which means that you need to decompose the original class.

Practice:

• Decide how to break down the responsibilities of the class.
• Create a new class that shows responsibility for separating from the old class. Rename the old class if the remaining responsibility for the old class does not match the old class name.
• Establish a connection relationship that accesses the new class from the old class. If you need to access the old class from the new class, there may be a "two-way connection", unless you really need it, and do not establish a connection from the new class to the old class.
• For each field that you want to move, use the moves field for the removal.
• After each move, compile and test.
• Use the Move method to move the necessary functions from the old class to the new class. Here's a tip: Move the lower-level function (the function that is called by other functions) and move the higher-level function.
• After each move, compile and test.
• Check to streamline the interface for each class. If you set up a two-way connection, consider whether you can change them to one-way connections.
• Decide whether to expose the new class, and if not, you can make the old class completely the delegate class for the new class. If you really want to expose him, you have to consider the problem of aliasing, that is, when you publicly give other users a reference or a normal value object.

Example:

classperson{ Public: QString name () {returnM_name; } QString telephonenumber () {returnM_officeareacode +M_officenumber; } QString Officeareacode () {returnM_officeareacode; }        voidSetofficeareacode (ConstQString &value) {M_officeareacode=value; } QString Officenumber () {returnM_officenumber; }        voidSetofficenumber (ConstQString &value) {M_officenumber=value; }Private: QString m_name;    QString M_officeareacode; QString M_officenumber;};

After reading this example, we can see that we can put the features associated with the phone number in a separate "phone" class. First we define a telephone class to represent the concept of a telephone number.

class telephonenumber{   };

The next thing we do is build a connection from person to telephonenumber, which is to add a field to the person to save the Telephonenumber object

class person{private:    telephonenumber m_telephonenumber;};

Next we can use the Move field to move the fields associated with the phone, here is M_officeareacode and M_officenumber, first we're moving m_officeareacode we can get

class telephonenumber{    QString officeareacode ()    {        return  m_officeareacode;    }         void Setofficeareacode (const QString &value)    {        = value;    } Private :    QString M_officeareacode;};

This is what the target class looks like after the move field.

class person{public:        QString telephonenumber ()    {        return Officeareacode () + m_officenumber;    }        QString Officeareacode ()    {        return  m_telephonenumber.officeareacode ();    }         void Setofficeareacode (const QString &value)    {        m_ Telephonenumber.setofficeareacode (value);    }     Private :    Telephonenumber M_telephonenumber;};

This is the change of the old class after the Move field about the Officeareacode first off reference. Then I can move the other fields and use the Move method to move the related functions into the Telephonenumber class

classperson{ Public: QString name () {returnM_name; } QString telephonenumber () {returnM_telephonenumber.telephonenumber (); } telephonenumber Telephoneclass () {returnM_telephonenumber; }Private: telephonenumber m_telephonenumber; QString m_name;};classtelephonenumber{QString telephonenumber () {returnM_officeareacode +M_officenumber; } QString Officeareacode () {returnM_officeareacode; }        voidSetofficeareacode (ConstQString &value) {M_officeareacode=value; } QString Officenumber () {returnM_officenumber; }        voidSetofficenumber (ConstQString &value) {M_officenumber=value; }Private: QString M_officeareacode; QString M_officenumber;};

After we have done this we need to consider the need not to expose this new class to the user, I can let the old class be the delegate class of the new class to completely hide the new class, or it can be exposed directly to the user. If you consider disclosure, you need to consider the problem of aliasing, considering the consequences of returning value objects and referencing objects to yourself.

In the face of this problem, there are several options:

1. Allows any object to modify any part of the Telephonenumber object, that is, you turn the class into a reference object, and you can change the value object to a reference object by using changing value to reference. In this case, the person is the telephonenumber access point.
2. No one is allowed to modify the Telephonenumber object without the person object, that is, telephonenumber is not modifiable, and here you can use the C + + attribute const to decorate it.
3. Another way to do this is to copy a new object that is exactly the same as telephonenumber as a return, which may cause some confusion to other users, because he might think he has changed and why the original object has not changed. In addition, if the same Telephonenumber object is passed to multiple users, it can also cause an alias problem between users.

Extract class is a common technique to improve concurrent programs, how to understand? In a nutshell, he can allow you to lock down the two classes that have been decomposed, and if you have this requirement you can do so. Of course there are dangers, if you want to make sure that two objects are locked at the same time, there is a transaction problem involved in this area, need to use other types of shared locks, this is a complex area, than the general situation requires a more onerous mechanism, although the transaction is very practical, But here, if you write the transaction manager manually, it will go beyond the scope of most programmers ' responsibilities.

"Refactoring – Improving the design of existing code" reading notes----Extract Class