設計模式 流暢介面

2021-09-26 03:16:11 字數 2742 閱讀 3496

何為流暢介面？先上**string(「1」)(「2」)(「3」)(「4」)(「5」)。流暢介面從字面上看是用起來很順手，究竟是有多順手，又應用在**呢？相信你看完本文多少會有些答案了。

class


string


:public qstring 


string


(const qstring &str)


};
當我們需要往string增加字串時我們常規做法：

string str;


str.


("1");


str.


("2");


str.


("3");


str.


("4");


str.


("5"


);
string str;


str.


("1").


("2").


("3").


("4").


("5"


);
頭鐵君這時候跳出來說，qt君啊，你還是失算了。我還有更流暢的做法，你看：

string &


operator()


(const qstring &str)
通過string類過載()操作符後我還可以這樣做：

string


("1")(


"2")


("3")(


"4")


("5"


);
頭鐵君向我投來得瑟的目光，看得我瑟瑟發抖。

頭鐵君啊，你別老是這麼頭鐵，看來我要放大招了。你那做法那裡是流暢介面的精神啊，看到那麼多括號都怕了，你別說這是給別人用?！

頭鐵君，來看看我的做法吧。

string &


operator


<<


(const qstring str)
通過過載<<操作符做出類似管道效果的流暢介面。

string str;


str <<


"1"<<


"2"<<


"3"<<


"4"<<


"5";
頭鐵君看了不感驚嘆，還真是比我那堆括號好用啊。就是看起來有些眼熟的呀。哦，對了。原來和qdebug()原理相似的呀。

qdebug()


<<


"1"<<


"2"<<


"3"<<


"4"<<


"5";
頭鐵君出了名是頭鐵，還有其他的應用場合嗎？

來來來，別急。我們再看下qstring的arg()介面的使用。

qstring filename;


qstring size;


qstring md5;


qstring status =


qstring


("file info: file name: %1; size: %2; checksum md5: %3").


arg(filename)


.arg


(size)


.arg


(md5)


;
頭鐵君若有所思一會，立馬開啟電腦查了起來。看著頭鐵君桌面的卡布奇諾都涼了，他還在查。看起來凍的卡布奇諾更有味道，感覺就是太甜了。

哦，原來是這樣啊。這不就是builder模式嗎？通過返回自己的引用或指標來實現流式(鏈式)程式設計。明白了，頭鐵君抬頭看到我喝著他的卡布奇諾，為了避免尷尬，說了一句，今天天氣不錯哈。

network類只提供獲取ip，mask，gateway，dns的方法，而設定方法都被隱藏起來了。而真正實現設定網路屬性是通過networkbuilder類來進行操作。並可以通過它來體現流暢介面。

class


networkbuilder


;class


network


;class


networkbuilder


;
通過networkbuilder構建network屬性後通過build的呼叫返回network物件。

network::


builder()


.ip("192.168.1.1").


mask


("255.255.255.0").


gateway


("192.168.1.1").


dns(


"8.8.8.8").


build()


;
現實意義：

mysql窗體設計模式 介面設計模式

內容來自 designing inte ces 1。安全探索 safe exploration 2。即時滿足 instant gratification 人們希望立刻從他們的行為看到結果。使用者，特別是新使用者應該讓他在最初使用軟體的幾秒內就得到成功的體驗。即時滿足也意味著不應該把介紹性的功能隱藏在...

介面與工廠（設計模式）

介面是實現多重繼承的途徑，而生成遵循某個介面物件的經典方式就是工廠方法設計模式。這種方式與直接呼叫建構函式的不同，我們在工廠物件呼叫的是建立方法，該工廠的方法將生成介面的某個實現類的物件。理論上，通過這種方式，我們的 將完全與介面的實現分離，這就使得我們可以透明地將某個實現替換為另乙個實現。下面我們...

設計模式 （介面隔離原則）

介面有兩種型別 建立單一介面，介面盡量要細化，同時介面中的方法盡量少 這回可能會有人問了，這跟單一職責原則不是相同的嗎 單一職責要求的是類和介面職責單一，強調的是職責，業務邏輯上的劃分 介面隔離要求介面的方法盡量少，需要盡量使用多個專門介面 下面舉個例子來說明 車的好壞都是口碑，質量和品牌 好車類 ...