Rebuild notes -- remove man-in-the-middle and remove man-in-the-middle

This article is in the study of the summary, welcome to reprint but please note the Source: http://blog.csdn.net/pistolove/article/details/44022341

In the previous article, we introduced "Hiding delegation relationships ". This article describes how to remove man-in-the-middle.

Let's learn about This refactoring method.

Open door

It is found that a class has performed too many simple delegation actions.

Solution: Let the customer directly call the delegate class.

Motivation

In "hiding the delegate relationship", we talked about "benefits of encapsulating the delegate object ". However, this encapsulation requires a price: whenever the customer wants to use the new features of the delegate class, you must add a simple delegate function on the server side. However, with more and more features of the delegate class, this process will make you suffer. At this time, the service class completely becomes a "man-in-the-middle", and the customer should directly call the trustee class.

It is hard to say under what circumstances it is more appropriate to hide. However, by "hiding the delegate relationship" and "removing the intermediary", we can coordinate well. Because it can be constantly adjusted during system operation. As the system keeps changing, the selection scale of "Hiding degree" also changes accordingly. Three months ago, the appropriate package may seem clumsy today. The significance of reconstruction is that you never have to say sorry for the problem you have encountered-you just need to fix the problem.

Practice
(1) create a function to obtain the trusted object. (2) For each delegate function, delete the function in the service class, and convert the customer who needs to call the function to call the delegate object. (3) process, compile, and test each delegate function.

Example
This example shows the example of "People and Departments" used in the previous article in another way. At the end of the previous refactoring, Person hides the Department:

class Person{//.....Department _department;public Person getManager(){return _department.get_manager();}}class Department{//.....private Person _manager;public Department(Person manager){_manager = manager;}}

To find someone's manager, the customer code may be written as follows:

manager = john.getManager();

In this way, Department usage and encapsulation are simple. However, if a large number of functions do this, they have to place a large number of delegate actions in the Person. In this case, the man in the middle should be removed. First, create a function in Person to obtain the delegate object:

class Person{//.....public Department getDepartment(){return _department;}}

Then, process each delegate function one by one. For every such function, you need to find the function used by Person and modify it. It first obtains the delegate object and then directly uses the latter:

manager = john.getDepartment().getManager();

Then, you can delete the getManager () function in Person. If something is missing, the compiler will tell you. For convenience, some delegates may be retained. In addition, you may want to hide the delegate relationship to some customers and allow others to directly use the delegate object.


This article mainly introduces the refactoring method-removing man-in-the-middle. This method is the opposite of "Hiding delegate relationships". It is precisely because of the opposite that it can be flexibly adapted in practical applications. Some delegate relationships may need to be retained, while others need to be removed, so that the customer can directly use the delegate object. These can be changed accordingly. There are no absolute rules for the use of different refactoring techniques, and they all need to be flexibly used based on actual conditions. The so-called "only flexibility can be invincible ". Finally, I hope this article will help you. If you have any questions, please leave a message. Thank you. (PS: the next article will introduce refactoring notes-introducing additional functions)