通過api呼叫元件的時候,需要涉及到元件的單例、多例模式。如果元件是單例的,在多次例項化的時候,只有乙個例項,對應的檢視層也只存在乙份;如果元件是多例的,那麼每次例項化的時候都會產生乙個新的例項,且對應的檢視也是多份的,它們之間互不影響。
在cube-ui中涉及到api呼叫的元件的基本都是彈層類,經常使用的如下:
- toast提醒
- picker選擇器
- timerpicker時間選擇器
- dialog彈窗
- actionsheet操作選單
所有的api呼叫都是使用create-api模組暴露出的createapi函式實現,在定義的時候就決定了該元件是否是單例的。
預設情況下,toast、dialog以及actionsheet是單例的,而picker和timepicker是多例的。如果想在例項化的時候改變預設行為,設定$createx
中的引數
const dialog = this.$createdialog(,false)
dialog.show()
一般情況下,預設行為就能滿足要求了。
限於picker和timepicker的場景,不支援單例模式
單例模式 之 單例模式 Holder
之前我寫過 單例模式中的餓漢模式和懶漢模式 他們雖然都能實現單例模式 但是優缺點很明顯 餓漢模式 不能懶載入 類載入就會被例項化 消耗很大,在併發情況下安全性很高。懶漢模式 能實現懶載入,但是在併發情況下安全性不是很高。雖然一步一步的優化,安全性得到了保證,但是卻使用了synchronized 對效...
單例模式之列舉單例
列舉也是餓漢式。列舉單例 問題1 列舉單例是如何限制例項個數的 反編譯後可以看到 就是我們列舉類的乙個靜態成員變數而已,單例項的 問題2 列舉單例在建立時是否有併發問題 沒有,因為它也是靜態成員變數,它的執行緒安全性也是在類載入階段完成的。那個時候不會有執行緒併發問題 問題3 列舉單例能否被反射破壞...
模式之單例模式
單例模式 要求乙個類有且只有乙個例項 物件 那首先先說一下訪問限定符 public 可以在類中 本類 子類 其他類 類外訪問 protected 可以在本類 以及子類中訪問 private 只可以在本類類中訪問 那麼我的理解是 如果只能有乙個物件,那麼肯定與建構函式有關,所有物件的初始化都要經過建構...