"Refactoring – Improving the design of existing code" reading notes----Hide Delegate

A delegate relationship is a class that, for another class, simply forwards the interface, that is, the client invokes another object through a delegate class. A straightforward delegation relationship is that the delegate class directly returns the target class to the client, which is cumbersome because the change in the delegate relationship affects the client's code. The secret entrusted relationship is healthy, and when you are completely hidden, the change in your delegation will only occur within the delegate class, thus not affecting the customer.

Encapsulation is one of the most critical features of object-oriented. He means that every object in the system should know as little as possible about the rest of the system, and the benefit is that once the changes have been made, there are fewer objects to learn about the change, which means that the code you need to change can be very small, making the changes easier to do.

In C + + you can openly declare the field as public, but you should try to hide this field, exposing this field can be a lot of trouble, should try to use protected or private. As your development experience grows richer, you will find that there are many other things that can be encapsulated.

If a customer needs a service object (the delegate object) to get another object to invoke the function of another object, then the client has to know this level of delegation, and in the event of a change in the delegation relationship, the customer will have to change accordingly. You can remove this dependency by placing a simple delegate function on the service object that hides the delegate relationship. In this way, if the delegate relationship changes later, the change is only limited to the service object and does not involve the customer. For some or all of your customers, you may find it necessary to use the extract Class first, and once you have hidden relationships with all customers, you no longer need to expose the objects that are being entrusted to the service object.

Practice:

• For each function in the delegate relationship, a simple delegate function is established in the service object.
• Adjust the customer, and he only calls the functions provided by the service object.
• Compile and test after each adjustment.
• If no customer needs to be shown in the future to get the Trustee class, then you can completely remove the relevant access function from the service object.
• Compile, test.

Example:

classperson{Department*department ()Const    {        returnm_department; }    voidSetdepartment (Department *value) {m_department=value; }    Private: Department*m_department;};classdepartment{ Public: Department ( person*Person ): M_manager (person) {} person*manager ()Const        {            returnM_manager; }    Private: QString M_chargecode; person*M_manager;};

We can see that there are two classes of person and department, we look at the client code, if I have a person, I want to get his manager, we must first call to get his department and then go to call Mana

Manager = John->department ()->manager ();

As you can see, this method of invocation undoubtedly exposes the client code to how the Department class works, and we can get the logic that department used to track the manager's information. This undoubtedly increases the coupling between the customer code and the Department, and to eliminate this coupling we have to hide delegate to establish a delegate function in person

class person{    public:        *Manager ()        {            m_departmentManager ();        }};

Then we modify the client code and let him call the new function instead.

Manager = John->manager ();

As you can see, after this modification, the client code knows nothing about department, so my client code is stable no matter what changes are made between the inside of my person class and department. Even if we complete the delegate to all the functions of department and modify all the clients of person accordingly, I can remove the Access function to department in person.

Ger

"Refactoring – Improving the design of existing code" reading notes----Hide Delegate