Rebuilding notes -- hiding "delegated relationships"

Rebuilding notes -- hiding "delegated relationships"

 

 

In the previous article, we introduced "associating classes ". This article describes how to reconstruct the hidden principal relationship.

Let's learn about This refactoring method.

 

 

Open door

Discovery: the customer calls another object through a delegate relationship.

Solution: create all functions required by the customer in the service class to hide the delegate relationship.

 

 

Motivation

We all know that "encapsulation" is one of the most critical features, even if it is not the most critical feature of an object. "Encapsulation" means that every object should have as little knowledge as possible about other parts of the system. In this way, once a change occurs, there will be fewer objects to understand the change-this will make the change easier.
If a customer first obtains another object through the service object field and then calls the latter function, the customer must be aware of this delegation relationship. In case of a change in the delegated relationship, the customer must also change accordingly. Then, we can place a simple delegate function on the server object to hide the delegate relationship and remove this dependency. In this way, even if the delegate relationship changes in the future, it will only be in the server object and will not involve the customer.

For some or all customers, you may find it necessary to use the "refining class". Once you have hidden the delegate relationship from all the customers, you no longer need to publish the delegated object in the interface of the server object.

 

 

 

 

Practice
(1) create a simple delegate function on the server side for each function in the delegate relationship. (2) Adjust the customer so that it only calls the functions provided by the server object. (If the user and the service provider are not in the same package, consider modifying the access permission of the delegate function so that the customer can call it outside the package.) (3) Compile and test each adjustment. (4) If no customer needs to use the delegate class in the future, the access functions related to the service object can be removed. (5) Compile and test.


Example
This example starts with two classes: the person class representing the "person" and the department representing the "department:

class Person{Department _department;public Department get_department() {return _department;}public void set_department(Department _department) {this._department = _department;}}

class Department{private String _changeCode;private Person _manager;public Person get_manager() {return _manager;}public void set_manager(Person _manager) {this._manager = _manager;}//......}

If the customer wants to know who a person's manager is, he must first obtain the Department object:

Person john = new Person();Person manager = john.get_department().get_manager();

This code exposes the customer how the Department works, so the customer knows that the Department is used to track the "manager" information. If the Department is hidden from the customer, coupling can be reduced. To achieve the expected purpose, create a simple delegate function in Person:

public Person getManager(){return _department.get_manager();}

Now, you need to modify all users of Person to use the new function:

Person manager = john.getManager();

You can remove the access function get_department () in Person after completing the delegate relationship for all functions of the Department and modifying all users of the Person accordingly.



This article mainly introduces the refactoring method-hiding the "delegation relationship ". This method seems quite simple, with the main purpose of reducing coupling in the Code. The use of this method also depends on the specific situation, in the next article, the "Remove man-in-the-middle" method is the opposite, so flexible use is very important. Now, I am still at the initial level and look forward to improving slowly. Finally, I hope this article will help you. If you have any questions, please leave a message. Thank you. (PS: next article will introduce refactoring notes -- remove man-in-the-middle)