主頁 > 軟體設計 > MVIKotlin學習筆記(2):Store

MVIKotlin學習筆記(2):Store

2022-03-10 16:00:15 軟體設計

Store

Store用來寫業務邏輯,

MVIKotlin中用Store介面表示,

介面特性

  • 三個引數:輸入Intent、輸出StateLabel
  • 屬性state回傳當前StoreState
  • 可以在任何執行緒實體化,
  • 函式states(Observer<State>)用于訂閱State的更新,訂閱時他會發出StoreState,可以在任何執行緒呼叫,States總是在主執行緒上發出,
  • 函式labels(Observer<Label>)用于訂閱Labels,可以在任何執行緒呼叫,Labels總是在主執行緒上發出,
  • 函式accept(Intent)用于給Store補給Intents,只能在主執行緒呼叫,
  • 函式init()用于初始化Store,如果可以的話會觸發Bootstrapper,只能在主執行緒呼叫,
  • 函式dispose()用于釋放Store并取消它的所有異步操作,只能在主執行緒呼叫,

states(Observer<State>)labels(Observer<Label>)通常不直接使用,可以使用擴展Reaktivekotlinx.coroutines類別庫(詳見生命周期),只有在自定義擴展時會用到這些函式,

組件

任何Store最多只有三個組件:引導程式(Bootstrapper)、執行者(Executor)與縮減器(Reducer),

Reducer為什么叫縮減器:https://blog.csdn.net/uwenhao2008/article/details/79613717

Store

Bootstrapper

用于快速啟動Store

如果Bootstrapper被傳遞給StoreFactory,它會在Store的初始化期間被執行,

Bootstrapper生產ActionsExecutor處理,

Bootstrapper總是在主執行緒執行,Actions也只能在主執行緒調度,在Bootstrapper執行時可以自由切換執行緒,

Bootstrapper是有狀態的,不能作為單例使用,

Executor

Executor用來寫業務邏輯,所有的異步操作都發生在這里,

Executor接收并處理來自外部的Intents與來自內部的Actions

Executor有兩種輸出:MessagesLabels

  • Messages被傳遞給Reducer

  • Labels被直接發送到外部,

Executor持續訪問StoreState,在Message被調度后,新的StateExecutor來說是可見的,

Executor總是在主執行緒執行,MessagesLabels也只能在主執行緒調度,在ActionIntents處理時可以自由切換執行緒,

Executor是有狀態的,不能作為單例使用,

Reducer

Reducer是一個函式,它接收來自ExecutorMessageStoreState作為引數,回傳一個新的State

Reducer在任何Message被生產后呼叫,呼叫回傳后應用并發送新的State

Reducer總是在主執行緒呼叫,

創建Store

通常不需要直接實作Store介面,應該使用StoreFactory來創建,只需要將BootstrapperExecutorReducer傳入并初始化State即可,可以在不同的情況下使用不同的StoreFactory并在需要的時候組合他們,

一些由MVIKotlin提供的Factory:

  • DefaultStoreFactory 創建默認的Store實體,由mvikotlin-main模塊提供,
  • LoggingStoreFactory 包裝另一個StoreFactory并添加日志記錄,由mvikotlin-logging模塊提供,
  • TimeTravelStoreFactory 創建具有時間旅行功能的Store,由mvikotlin-timetravel模塊提供,

初始化Store

默認情況下,StoresStoreFactory自動初始化,可以通過設定StoreFactory.create(...)函式的autoInit引數為false來禁用自動初始化,

如果自動初始化被禁用,你應該使用Store.init()函式進行手動初始化,

IDEA動態模板

用于快速創建新的Store:https://gist.github.com/arkivanov/34bb84e73e56c22a4e7c752421d5f02c

最簡單的例子

這個例子會創建一個簡單的計數器Store,它可以實作增加或減少它的值,

定義介面

首先,定義一個介面,它看起來像這樣:

internal interface CalculatorStore : Store<Intent, State, Nothing> {

    sealed class Intent {
        object Increment : Intent()
        object Decrement : Intent()
    }

    data class State(
        val value: Long = 0L
    )
}

CalculatorStore介面本身可以標記為internal,因此這是一個模塊的具體實作,

同時,CalculatorStore有兩個Intents(IncrementDecrement)并且State有一個Long型別的屬性value,這是這個Store的公開API部分,

實作工廠

接下來是Store的實體化工廠:

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            initialState = State(),
            reducer = ReducerImpl
        ) {
        }

    private object ReducerImpl : Reducer<State, Intent> {
        override fun State.reduce(msg: Intent): State =
            when (msg) {
                is Intent.Increment -> copy(value = https://www.cnblogs.com/xuankaicat/p/value + 1L)
                is Intent.Decrement -> copy(value = value - 1L)
            }
    }
}

我們只需要Reducer組件,它接受Intents并且通過遞增或遞減value的值來修改State

工廠的create()函式使用作為依賴項傳遞的StoreFactory

增加Executor

目前CalculatorStore只能遞增或遞減它的值,接下來我們需要實作計算從1加到value的總和,我們需要一個新的Intent

internal interface CalculatorStore : Store<Intent, State, Nothing> {

    sealed class Intent {
        object Increment : Intent()
        object Decrement : Intent()
        data class Sum(val n: Int): Intent() // <-- 增加了這行
    }

    data class State(
        val value: Long = 0L
    )
}

目前的想法是CalculatorStore會接收Intent.Sum(N),計算從1加到value的總和并使用計算得到的值更新State,但是這個計算是很耗時的,所以我們應該讓它在后臺執行緒中執行,因此我們需要Executor

為了讓Executor可以和Reducer進行通信,我們需要Messages

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    private sealed class Msg {
        class Value(val value: Long) : Msg()
    }
}

我們需要一個新的Reducer,現在它可以通過接收Messages來代替Intents了:

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    private sealed class Msg {
        class Value(val value: Long) : Msg()
    }

    private object ReducerImpl : Reducer<State, Msg> {
        override fun State.reduce(msg: Msg): State =
            when (msg) {
                is Msg.Value -> copy(value = https://www.cnblogs.com/xuankaicat/p/msg.value)
            }
    }
}

Msg.Value(Long)用來替換Statevalue的值,

接下來是Executor,我們不需要實作整個介面,只需要擴展基本實作即可,

兩個由MVIKotlin提供的Executors基本實作:

  • ReaktiveExecutor 基于Reaktive庫實作,由mvikotlin-extensions-reaktive模塊提供,
  • CoroutineExecutor 基于協程實作,由mvikotlin-extensions-coroutines模塊提供,

兩個都來嘗試一下:

ReaktiveExecutor
internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    // ...

    private class ExecutorImpl : ReaktiveExecutor<Intent, Nothing, State, Msg, Nothing>() {
        override fun executeIntent(intent: Intent, getState: () -> State) =
            when (intent) {
                is Intent.Increment -> dispatch(Msg.Value(getState().value + 1))
                is Intent.Decrement -> dispatch(Msg.Value(getState().value - 1))
                is Intent.Sum -> sum(intent.n)
            }

        private fun sum(n: Int) {
            singleFromFunction { (1L..n.toLong()).sum() }
                .subscribeOn(computationScheduler)
                .map(Msg::Value)
                .observeOn(mainScheduler)
                .subscribeScoped(onSuccess = ::dispatch)
        }
    }

    // ...
}

ExecutorImpl繼承自ReaktiveExecutor并實作了executeIntent方法,executeIntent提供了一個Intent和一個當前State的提供者,對于Intent.IncrementIntent.Decrement只需要簡單地發送一個帶有由dispatch函式包裝的新的值的Message,但對于Intent.Sum需要用到Reaktive來進行多執行緒處理:在computationScheduler中求和,然后轉換到mainScheduler并使用dispatch來發送Message

ReaktiveExecutor實作了Reaktive的 DisposableScope,它提供了許多擴展函式,我們使用了其中之一:subscribeScoped,這樣可以確保在Store被釋放時訂閱也可以被釋放,

CoroutineExecutor
internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    // ...

    private class ExecutorImpl : CoroutineExecutor<Intent, Nothing, State, Msg, Nothing>() {
        override fun executeIntent(intent: Intent, getState: () -> State) =
            when (intent) {
                is Intent.Increment -> dispatch(Msg.Value(getState().value + 1))
                is Intent.Decrement -> dispatch(Msg.Value(getState().value - 1))
                is Intent.Sum -> sum(intent.n)
            }

        private fun sum(n: Int) {
            scope.launch {
                val sum = withContext(Dispatchers.Default) { (1L..n.toLong()).sum() }
                dispatch(Msg.Value(sum))
            }
        }
    }

    // ...
}

ExecutorImpl繼承自CoroutineExecutor,求和程序在Default調度器中被執行,MessageMain執行緒中被調度,

CoroutineExecutor提供了名為scopeCoroutineScope屬性,我們可以用它來執行異步任務,scope的默認調度器是Dispatchers.Main,可以通過傳給CoroutineExecutor的建構式不同的CoroutineContext來重寫默認調度器,在Store被釋放時scope會自動取消,

發布Labels

Labels是由Store(或Executor)生產的一次性事件,一旦Labels被發布,它們會被當前所有的訂閱者接收并且不會快取,Executor有一個專門用來發布Label的函式:publish(Label)

創建Store

我們需要將Executor的構建工廠交給StoreFactory

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            initialState = State(),
            executorFactory = ::ExecutorImpl, // <-- 交付Executor的工廠
            reducer = ReducerImpl
        ) {
        }

    // ...
}

為什么要使用構建工廠而不是直接使用一個Executor的實體呢?因為前者可以實作時間旅行功能,在除錯時間旅行事件時,它會在必要時創建單獨的執行器實體,并偽造它們的States

增加Bootstrapper

當我們需要創建Store的一個新的實體時,它會保持一個初始化State并什么都不做,直到你提供了一個Intent,但有時需要引導啟動一個Store,在它被創建時做一些額外的事情,例如,它可以開始從服務端接收事件,或從資料庫中讀取一些資料,這就是Bootstrapper要做的事:生產Actions并交給Executor運行,就像Intents一樣,

CalculatorStore能夠計算從1到N的和,目前它會在接收到Intent.Sum(N)時執行這一步驟,讓我們使用Bootstrapper來讓CalculatorStore被創建時計算sum(100)Executor已經實作了計算的具體程序,所以我們只要發送一個觸發ActionExecutor,就像Intent.Sum(N)

首先,添加一個Action

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    // ...

    private sealed class Action {
        class Sum(val n: Int): Action()
    }

    // ...
}

然后,在ReaktiveExecutor中處理這個Action

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    // ...

    private class ExecutorImpl : ReaktiveExecutor<Intent, Action, State, Msg, Nothing>() {
        override fun executeAction(action: Action, getState: () -> State) =
            when (action) {
                is Action.Sum -> sum(action.n)
            }

        // ...
    }

    // ...
}

或者在CoroutineExecutor中來處理,是一樣的:

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    // ...

    private class ExecutorImpl : CoroutineExecutor<Intent, Action, State, Msg, Nothing>() {
        override fun executeAction(action: Action, getState: () -> State) =
            when (action) {
                is Action.Sum -> sum(action.n)
            }

        // ...
    }

    // ...
}

最后,我們需要觸發這個Action,我們需要將一個Bootstrapper傳給StoreFactory,對于這種簡單的情況,我們只需要使用SimpleBootstrapper

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            initialState = State(),
            bootstrapper = SimpleBootstrapper(Action.Sum(100)), // <-- 增加了這行
            executorFactory = ::ExecutorImpl,
            reducer = ReducerImpl
        ) {
        }

    // ...
}

SimpleBootstrapper只調度了提供的Actions,但有時我們可能需要其他的引導程式,例如后臺作業:

使用來自mvikotlin-extensions-reaktive模塊的ReaktiveBootstrapper

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            initialState = State(),
            bootstrapper = BootstrapperImpl, // <-- 傳BootstrapperImp給 StoreFactory
            executorFactory = ::ExecutorImpl,
            reducer = ReducerImpl
        ) {
        }

    private sealed class Action {
        class SetValue(val value: Long): Action() // <-- 使用另一個Action
    }

    // ...

    private class BootstrapperImpl : ReaktiveBootstrapper<Action>() {
        override fun invoke() {
            singleFromFunction { (1L..1000000.toLong()).sum() }
                .subscribeOn(computationScheduler)
                .map(Action::SetValue)
                .observeOn(mainScheduler)
                .subscribeScoped(onSuccess = ::dispatch)
        }
    }

    private class ExecutorImpl : ReaktiveExecutor<Intent, Action, State, Msg, Nothing>() {
        override fun executeAction(action: Action, getState: () -> State) =
            when (action) {
                is Action.SetValue -> dispatch(Msg.Value(action.value)) // <-- 處理Action
            }

        // ...
    }

    // ...
}

ReaktiveBootstrapper也實作了DisposableScope,就像ReaktiveExecutor一樣,所以我們也可以在這里使用subscribeScoped函式,

使用來自mvikotlin-extensions-coroutines模塊的CoroutineBootstrapper

internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            initialState = State(),
            bootstrapper = BootstrapperImpl,
            executorFactory = ::ExecutorImpl,
            reducer = ReducerImpl
        ) {
        }

    private sealed class Action {
        class SetValue(val value: Long): Action()
    }

    // ...

    private class BootstrapperImpl : CoroutineBootstrapper<Action>() {
        override fun invoke() {
            scope.launch {
                val sum = withContext(Dispatchers.Default) { (1L..1000000.toLong()).sum() }
                dispatch(Action.SetValue(sum))
            }
        }
    }

    private class ExecutorImpl : CoroutineExecutor<Intent, Action, State, Msg, Nothing>() {
        override fun executeAction(action: Action, getState: () -> State) =
            when (action) {
                is Action.SetValue -> dispatch(Msg.Value(action.value))
            }

        // ...
    }

    // ...
}

CoroutineBootstrapper也提供了名為scopeCoroutineScope屬性,就和CoroutineExecutor一樣,所以我們可以用它來執行異步任務,

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/440447.html

標籤:架構設計

上一篇:微服務工程中,基礎組件應用

下一篇:從前,有一個簡單的通道系統叫尤娜……

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more