Delegate: Class a delegates the function to class b
Class A contains a function class b pointer or object. When the function of b function class is used, the function of b is called through its pointer or object. In the view of the calling module, the problem is solved by class A. in fact, class a solves the problem through its member class b object or pointer. This process is "A entrusts b to complete the problem".
Incidentally, a dependent on b refers to the pointer of a class containing a base class of b, which is not necessarily a base class object, because the base class may be a virtual base class and cannot produce an object.

Facade mode: or appearance mode (is it the front desk? Have a cup of coffee.)

Definition: the external and internal communication of a subsystem must be carried out through a unified object.

Translation:
Subsystem: it is composed of one or more function classes, generally a group of function classes. After a series of processing of one or some businesses, a service content is realized.

Unified object (facade): a class,
In this class, all functional classes that are called in the subsystem are dependent on (including functional class base classes) or related (including functional subclasses).
This class only provides one external interface (only one public function, and the remaining data or function access permissions are not public) to represent externally callable services;
In this open interface function, it is necessary to call the function classes in all subsystems to meet the requirements,
When the requirements change, the internal dependent or associated function classes and call logic are extended according to the requirements, and the service interface functions provided by this class remain unchanged,

effect:
Decouple the function class from the high-level calling module to reduce the interdependence of the system,
External access to the subsystem will lead to strong coupling, low cohesion and difficult maintenance;
A service interface of external access facade class can be weakly coupled, highly cohesive and easy to expand internally,
It has no effect on the caller because the external interface has not changed.

advantage:
Reduce dependency and coupling, mainly the dependency and coupling between calling modules and subsystem function classes.
The use is flexible, the facade interface remains unchanged, and the subsystem moves freely.
Safe, the method not opened on the facade cannot be accessed externally.

Disadvantages:
It does not comply with the opening and closing principle. It is closed for modification and open for expansion. When there are errors that need to be repaired after the system is put into operation, it can only modify the code of the facade, and inheritance and overwriting are not useful. Therefore, it is necessary to be cautious in design.

Usage scenario:
Provide an excuse for a complex module or subsystem to be accessed by the outside world.
The subsystem is relatively independent and is a black box to the outside, such as calculating interest, health score, comprehensive score, etc.
To prevent the risk diffusion caused by low-level personnel, low-level technicians in project development are easy to affect the overall project due to the quality of personal code, so it is necessary to specify their development in the specified subsystem, and then provide an interface for access operation.

A scene in which a subsystem has multiple facade:
The facade is too big to bear: if the code exceeds 200 lines, it is recommended to split it.
The subsystem has different access paths: different levels, different permissions, different resources, etc. you can extend the facade (inheritance or agent).

Note:
Facade classes should not participate in business logic.
Reason: the facade class encapsulates the service and is directly opened to the outside world. This requires the stability of the facade class, which means less modification,
If there are business logic components in the interface opened to the outside world of the facade class, such as calling function a, then function b, and then function c, when the business changes, the facade will be changed accordingly. The business logic depends on the facade class, resulting in the instability of the facade class.
Methods to avoid facade classes participating in business logic:
In the subsystem, there should be not only functional classes to realize functions, but also business logic classes to combine functions to form a complete business and provide the business interface. The facade class uses the interface provided by the business logic class to provide services to the outside world. By adding business logic classes to the subsystem, the facade class is decoupled from the business logic and is only responsible for providing service interfaces to the outside world, And delegate external requirements to business logic classes.

Code example: the front desk does not produce coffee, but just the porter of coffee, and entrusts the task of producing coffee to the kitchen

//Beverages
class Drink
{
public:
	Drink()
	{
		kind = 0;
	}

	Drink(int value)
	{
		kind = value;
	}

	void get()
	{
		if (kind < 2)
		{
			cout << "A cup of herbal tea" << "be ready" << endl;
		}
		else if (kind < 4)
		{
			cout << "A glass of milk" << "be ready" << endl;
		}
		else if (kind < 6)
		{
			cout << "A cup of coffee" << "be ready" << endl;
		}
		else
		{
			cout << "A drink" << "be ready" << endl;
		}
	}

	int GetKind()
	{
		return kind;
	}

protected:
	int kind;
};

//Kitchen staff
class WaterPullIn
{
public:
	Drink* Handle(Drink* drink)
	{
		return (new Drink(drink->GetKind() + 1));
	}
};

//Kitchen staff
class SugarPullIn
{
public:
	Drink* Handle(Drink* drink)
	{
		return (new Drink(drink->GetKind() + 1));
	}
};

//Kitchen staff
class MilkPullIn
{
public:
	Drink* Handle(Drink* drink)
	{
		return (new Drink(drink->GetKind() + 1));
	}
};

//Kitchen staff
class CoffeeBeanPullIn
{
public:
	Drink* Handle(Drink* drink)
	{
		return (new Drink(drink->GetKind() + 1));
	}
};

//The kitchen category includes all kitchen staff and provides beverage supply services
class Kitchen
{
public:
	Drink* GetCoffee()
	{
		mDrink = new Drink();
		mDrink = mWaterPullIn->Handle(mDrink);
		mDrink = mSugarPullIn->Handle(mDrink);
		mDrink = mMilkPullIn->Handle(mDrink);
		mDrink = mCoffeeBeanPullIn->Handle(mDrink);
		return mDrink;
	}

	Drink* GetMilk()
	{
		mDrink = new Drink();
		mDrink = mWaterPullIn->Handle(mDrink);
		mDrink = mMilkPullIn->Handle(mDrink);
		return mDrink;
	}

	Drink* GetCooltea()
	{
		mDrink = new Drink();
		mDrink = mWaterPullIn->Handle(mDrink);
		return mDrink;
	}

protected:
	Drink* mDrink;
	WaterPullIn* mWaterPullIn;
	SugarPullIn* mSugarPullIn;
	MilkPullIn* mMilkPullIn;
	CoffeeBeanPullIn* mCoffeeBeanPullIn;
};

//Front class, that is, facade class
class Stage
{
public:
	void SetKitchen(Kitchen* kitchen)
	{
		mKitchen = kitchen;
	}

	Drink* GetCoffee()
	{
		return mKitchen->GetCoffee();
	}

protected:
	Kitchen* mKitchen;
};

void func()
{
	Kitchen* WaiBao = new Kitchen();
	Stage* HotelStage = new Stage();
	HotelStage->SetKitchen(WaiBao);

	//Order a cup of coffee at the front desk
	Drink* Coffee = HotelStage->GetCoffee();
	Coffee->get();
}

int main()
{
	func();
	return 0;
}

The running result is correct. In this code, the facade class Stage receives the customer's request for coffee, but does not make coffee. Instead, it delegates the service to the Kitchen kitchen. The Kitchen class includes the function classes for making drinks, WaterPullIn, SugarPullIn, milkPullIn and coffee bean pullin. The Kitchen realizes "making coffee" to the business logic by calling these function classes And several other drinks to provide services. Together with the function class, the facade class forms a subsystem of the facade class. The facade class does not participate in functions and businesses, but is only responsible for receiving and delegating. In the view of the calling module customer, this facade system is quite stable and simple.