故事線
經過一番打拼，廣軍覺得這個模式挺好用的，賺錢多，他就想著啊，既然這套模式這么的好，那我為什么不開連鎖店？
對咯，人手不夠啊，“安得猛士兮守四方？”
于是，他馬上出了招聘廣告，預計需要三個店長，因為他想開三家連鎖，然后他自己當那個“幕后黑手”，這小日子過得，豈不美哉？
但是吧，他又怕找了這些店長之后，這些店長的辦事風格和他不一樣，破壞了老用戶的體驗，萬一照成了客戶流失就不好了，于是他規定：各位店長執行作業時，以我的作業方式為準則，可以超越，但是不能篡改！
好極，就這樣的苛刻條件，前來應聘的人絡繹不絕啊，為啥呢？一個店鋪一個月的凈利潤是3W（稅前），他直接給店長開了1W工資，好家伙，真是會算賬，不愧是我們的廣軍，想想，多少人擠破頭，頭懸梁錐刺股，到頭來一個月也就一萬多，而跟著廣軍混，吃香的喝辣的，而廣軍的純收入也就從一開始的2W變成了6W，作業量從996變成了，不知道，廣軍胸懷大志，肯定有更重要的事情要做，說不定在盤算著盤下哪家店呢，
而他找的這些店長，也并非等閑之輩，各個都“身懷絕技”，在廣軍教他們做事的基礎上，又添加了自己的做事方法，比如說，客戶點菜前給用戶推薦每周的優惠套餐，用戶點菜后送一杯免費的茶，這些舉動都深深的抓住了客戶們的心，由此，廣軍的漢堡店的生意蒸蒸日上，他也把這些店長的工資做了不同程度上的提高，
故事到此就結束了嗎？并不是的，你以為這些店長們都只有這么一個身份嗎？你錯了，其實，他們當中有的是列印店的老板，所以給用戶列印小傳單，有的是飲料店的推銷員，所以給客戶準備一些免費的茶，反正羊毛出在羊身上，銷量增加，廣軍也就睜一只眼閉一只眼了，這是我們廣軍的容人之量，鬼才就是鬼才，知人善用，
代理模式
何為代理模式？這就是代理模式，
代理模式，控制對一個物件的訪問，為其他物件提供一種代理以控制對這個物件的訪問，在某些情況下，一個物件不適合或者不能直接參考另一個物件，而代理物件可以在客戶端和目標物件之間起到中介的作用，
那我們先來看一下廣軍找店長這件事情的類圖呈現：
再來看一下代碼實作：
#include<iostream>
using namespace std;
//抽象主題
class abstractMan {
public:
virtual void run() = 0;
};
class boss :public abstractMan {
public:
void bread() { cout << "bread" << endl; }
void roast() { cout << "roust" << endl; }
void run() {
bread();
roast();
}
};
//代理
class proxy :public abstractMan {
public:
proxy(abstractMan* temp) { a = temp; }
void before(){
cout<<"before"<<endl;
//該干嘛干嘛
}
void after(){
cout<<"after"<<endl;
//愛干嘛干嘛
}
void run() {
before();
a->run();
after();
}
private:
abstractMan* a;
};
//場景
int main()
{
abstractMan* bs = new boss();
proxy* pro = new proxy(bs);
pro->run();
}
代理里面的before和after方法，就是給代理的自由權限，
在Java里面，有時候會看到說靜態代理和動態代理的，那諸君看看我上邊那個是靜態的，還是動態呢？
小tip：
靜態：一個代理綁死一個客戶
動態：根據場景確定代理物件，可支持多代理，
多代理：
前邊說道，某個店長他們可能會身兼多職，那么就相當于他們有多重代理身份，這些又該如何實作？代理中的before和after方法又該如何取舍？（代理類是自己寫的，被代理類是封裝好的）
一千個讀者自有一千個哈姆雷特，相信大家想想就會有自己的想法了，
廣軍的故事還會持續更新，看故事，學模式，跟緊我
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/109379.html
標籤：其他
上一篇：求助求助 pycharm 進入后一直 discover binary moudle 或者updating
下一篇：python編程，有大佬相助嗎？