前言

接上一次的帖子，今天講一下我再 UI 自動(dòng)化中常用的設(shè)計(jì)模式。 由于網(wǎng)上已經(jīng)有非常多的文章詳細(xì)講解了設(shè)計(jì)模式的編碼實(shí)現(xiàn)，所以我今天也就不講實(shí)現(xiàn)細(xì)節(jié)了。 就是講我也講不出什么花來(lái)，只是網(wǎng)上的文章基本都是講解設(shè)計(jì)模式的本身實(shí)現(xiàn)，很少針對(duì)某一領(lǐng)域的實(shí)際場(chǎng)景去講具體改怎么用設(shè)計(jì)模式。 所以今天我只針對(duì)一些實(shí)際的場(chǎng)景來(lái)說(shuō)一下如何使用這些設(shè)計(jì)模式來(lái)完善 UI 自動(dòng)化。

工廠

每種語(yǔ)言實(shí)現(xiàn)設(shè)計(jì)模式的方式都不一樣，這里僅以 java 為例。 一般來(lái)說(shuō)，工廠模式是為了把創(chuàng)建一個(gè)對(duì)象的操作都集中在一起管理，其他所有需要用到這個(gè)對(duì)象的代碼都調(diào)用工廠類來(lái)創(chuàng)建對(duì)象。 在 UI 自動(dòng)化中，工廠類有一個(gè)重要的作用就是提供數(shù)據(jù)的能力。 這里直接上一個(gè)例子， 在我的項(xiàng)目中有這樣一個(gè)場(chǎng)景， 我們的測(cè)試都分模塊的， 不同的模塊有不同的 QA。 測(cè)試模型中心模塊的 QA 想要測(cè)試的話就需要依賴建模 IDE 來(lái)產(chǎn)出各種各樣的模型。 那根據(jù)上一個(gè)帖子我講到的一個(gè)設(shè)計(jì)原則–模塊間有數(shù)據(jù)依賴的時(shí)候。每個(gè)模塊自己負(fù)責(zé)提供對(duì)外接口。 模型 IDE 的 QA 需要提供一個(gè)可以生產(chǎn)出各種不同模型的 API 來(lái)。 如下：

上面我們我們用一個(gè)簡(jiǎn)單工廠來(lái)實(shí)現(xiàn)創(chuàng)建各種模型。 其他模塊調(diào)用此工廠方法滿足自己對(duì)模型的需求。 如果我們創(chuàng)建模型的類型更復(fù)雜的話，可以引入工廠模式和抽象工廠模式。 但實(shí)際上我最常用的還是簡(jiǎn)單工廠，偶爾用工廠模式抽象工廠基本沒(méi)用過(guò)。使用設(shè)計(jì)模式的時(shí)候最容易出現(xiàn)的是過(guò)度設(shè)計(jì)， 把過(guò)于復(fù)雜的模式硬搬到項(xiàng)目中來(lái)。 這是不可取的。

那接下來(lái)說(shuō)一說(shuō)這個(gè)工廠存在的意義吧。 簡(jiǎn)單工廠算是設(shè)計(jì)模式里最簡(jiǎn)單的了， 簡(jiǎn)單到它幾乎不是一個(gè)什么模式。 它其實(shí)只有一種思想，就是把創(chuàng)建一個(gè)東西的操作都統(tǒng)一放到一起，調(diào)用方只需要知道我要一個(gè)東西，我需要把什么參數(shù)傳遞進(jìn)來(lái)就可以得到這個(gè)東西。 比如我們的這個(gè)例子里，調(diào)用方只需要傳遞我需要一個(gè)什么類型的模型的參數(shù)。 至于如何創(chuàng)建這個(gè)模型它不需要知道，里面包含了多復(fù)雜的 UI 操作它也不需要知道。 這樣做的好處是：

• 代碼復(fù)用，我們使用工廠的來(lái)創(chuàng)建的東西一般都是比較復(fù)雜的，需要很多的步驟才能創(chuàng)建。 如果只是隨便 new 一下就可以得到的對(duì)象也就犯不著專門搞個(gè)工廠方法了。 如果任由寫 case 的人根據(jù)自己的想法去創(chuàng)建這些對(duì)象，不僅造成了很多的重復(fù)代碼。 而且這些碎片的話的代碼在后期的維護(hù)上也是一個(gè)難以接受的事情。

• 封裝變化，我們把創(chuàng)建模型的所有操作都統(tǒng)一放在一起。之后生產(chǎn)模型的操作發(fā)生變化，比如需求變動(dòng)。那我們只需要改動(dòng)這一處就可以了。而且調(diào)用方也完全不感知

• 解耦，就如開(kāi)始說(shuō)的那個(gè)設(shè)計(jì)原則一樣， 調(diào)用方不感知復(fù)雜的模型生產(chǎn)過(guò)程， 達(dá)到解耦的作用。 在 UI 自動(dòng)化中，尤其是業(yè)務(wù)邏輯特別復(fù)雜的大型項(xiàng)目中。 多人協(xié)作有個(gè)比較重要的點(diǎn)在這里提一下。 就是解耦，不要讓其他模塊的人感知自己模塊的任何實(shí)現(xiàn)細(xì)節(jié)。 他們了解的越少，操作的越少， 出錯(cuò)的概率就越小，學(xué)習(xí)成本就越小。 畫(huà)地為界，分而治之。 其實(shí)我個(gè)人覺(jué)得整個(gè)設(shè)計(jì)模式就是在解決兩件事情：解耦和代碼復(fù)用

單例

我們有了上面的工廠方法來(lái)幫助我們創(chuàng)建模型， 但是這里有個(gè)問(wèn)題。 就是我有太多的 case 依賴這些模型了。 如果每個(gè) case 都執(zhí)行一遍上面的操作重新創(chuàng)建一個(gè)模型的話會(huì)有兩個(gè)問(wèn)題：

• UI 操作尤其耗時(shí)，尤其是生產(chǎn)模型這種異步操作

• UI 本就不穩(wěn)定，這些重復(fù)的操作會(huì)增加 case 失敗的概率

所以我們希望除了有這種創(chuàng)建新模型的能力之外。 還能夠復(fù)用之前已經(jīng)產(chǎn)生的模型。 于是我們就有了使用單例模式的需求。 一般提到單例模式，基本上就是懶漢式，餓漢式什么的。 但這兩種大概率都是不可用的。 因?yàn)槭紫任覀兊牟僮魇茄舆t加載的，只有到了使用的時(shí)候才會(huì)去 UI 上執(zhí)行創(chuàng)建模型的操作。 總不能直接在類加載的時(shí)候就執(zhí)行吧。 至于在不加鎖的情況下判斷一下對(duì)象是否為 null 也是不行的。 因?yàn)楝F(xiàn)在的大規(guī)模 UI 自動(dòng)化都是并發(fā)執(zhí)行的。 所以可選的方案就是加鎖的雙重檢查機(jī)制以及靜態(tài)內(nèi)部類了。 這里主要講一下靜態(tài)內(nèi)部類吧， 雙重檢查機(jī)制估計(jì)大家都玩爛了。 如下：

• 靜態(tài)內(nèi)部類不會(huì)再 LRModel 的類加載的時(shí)候就加載，而是有人調(diào)用 getInstance 的時(shí)候才會(huì)加載。所以保證了延遲加載

• java 的 classloader 會(huì)保證靜態(tài)內(nèi)部類的線程安全，所以不用擔(dān)心并發(fā)的問(wèn)題

上面是靜態(tài)內(nèi)部類的實(shí)現(xiàn)方式，優(yōu)點(diǎn)是相較于鎖的雙重檢查方來(lái)說(shuō)實(shí)現(xiàn)起來(lái)簡(jiǎn)單，坑少。 比如沒(méi)有那個(gè)經(jīng)典的指令重排序的問(wèn)題。 當(dāng)然缺點(diǎn)也明顯， 就是一旦創(chuàng)建對(duì)象失敗， 那以后就再也沒(méi)有機(jī)會(huì)重新創(chuàng)建對(duì)象了。 而 UI 自動(dòng)化又是出了名的不穩(wěn)定。 所以還是要慎重的。

模板

模板模式在 UI 自動(dòng)化中比較常用的原因是在產(chǎn)品中有很多的操作路徑是復(fù)用的。 所以我們可以使用模板模式， 把固定的路徑抽象出來(lái)，由子類去實(shí)現(xiàn)那些獨(dú)立的邏輯。 比如：

上面是我們的產(chǎn)品引入一份數(shù)據(jù)的邏輯。 我們的數(shù)據(jù)引入有很多種類型。 比如從本地引入， 從數(shù)據(jù)庫(kù)引入，從 hdfs 引入，從 ftp 上引入等等等等。但是他們的基本步驟都是一樣的 (看截圖中的注釋)， 所以模板模式的思想是使用父類來(lái)規(guī)定到執(zhí)行操作的步驟， 為了代碼復(fù)用所以也會(huì)實(shí)現(xiàn)一些通用的步驟比如所有的引入都得點(diǎn)擊某些 button，填寫一些都行。 然后留下一些 abstract 的方法給子類實(shí)現(xiàn)。 這種父類規(guī)定骨架，子類實(shí)現(xiàn)細(xì)節(jié)的方式就是模板方法了。 在這里我們的父類定義好了所有的步驟，但是部分的具體實(shí)現(xiàn)細(xì)節(jié)由子類完成。 這里我們發(fā)現(xiàn)子類需要實(shí)現(xiàn)兩個(gè)方法

• 每個(gè)數(shù)據(jù)引入的關(guān)于生成 table 的操作的 setTableConfig

• 每種數(shù)據(jù)引入的文件配置方式操作的 setFileConfig

當(dāng)然模板方法也是可以有較深的結(jié)構(gòu)的。 比如上面說(shuō)的一些引入方式雖然都屬于數(shù)據(jù)引入，但是也分為兩大類， 一個(gè)是結(jié)構(gòu)化數(shù)據(jù)，一個(gè)是圖片數(shù)據(jù)。 而且凡是屬于結(jié)構(gòu)化數(shù)據(jù)的引入方式有很多步驟都是相同的。 凡是屬于圖片數(shù)據(jù)引入的方式的大部分步驟也是相同的。 所以我們繼續(xù)有抽象類如下：

上面是結(jié)構(gòu)化數(shù)據(jù)的抽象類。 他實(shí)現(xiàn)了父類 IDataload 的 setTableConfig 方法。 因?yàn)樗薪Y(jié)構(gòu)化數(shù)據(jù)引入的這個(gè)頁(yè)面操作都是一樣的。然后才是我們具體的本地文件的數(shù)據(jù)引入的類。如下。

這個(gè)具體的本地文件引入的類實(shí)現(xiàn)了方法 setFileConfig。 這樣我們就看到了這個(gè)模板模式的全貌。

• 基類 IDataload 負(fù)責(zé)定義執(zhí)行步驟，以及個(gè)別 UI 操作的實(shí)現(xiàn)。 規(guī)定子類必須實(shí)現(xiàn) setTableConfig 和 setFileConfig 這兩個(gè)方法

• 類 StructureDataLoad 繼承基類 IDataload，并實(shí)現(xiàn)了 setTableConfig 方法。 因?yàn)樗械慕Y(jié)構(gòu)化數(shù)據(jù)引入在這里使用的是同樣的頁(yè)面

• 具體的實(shí)現(xiàn)類 LocalFileDataLoad 繼承 StructureDataLoad，代表著本地?cái)?shù)據(jù)引入并實(shí)現(xiàn)了針對(duì)于本地文件引入所獨(dú)有的頁(yè)面操作 setFileConfig

所以實(shí)際上調(diào)用方要做的事情就是這樣的

模板模式的優(yōu)點(diǎn)：

• 代碼復(fù)用， UI 上很多操作路徑都是重復(fù)的，甚至說(shuō)不同的業(yè)務(wù)流程操作中的部分頁(yè)面使用的是相同的頁(yè)面。 使用模板模式可以很好的整理我們的代碼結(jié)構(gòu)，將業(yè)務(wù)邏輯分類并組織起來(lái)，可以服用的代碼由上層的父類實(shí)現(xiàn)。

模板模式的缺點(diǎn)：

• 如果類層級(jí)結(jié)構(gòu)較多的時(shí)候，維護(hù)起來(lái)有點(diǎn)麻煩。

策略

策略模式也是非常常用的， 甚至很多時(shí)候它是其他模式的基礎(chǔ)。 它的思想也特別簡(jiǎn)單。 當(dāng)初它誕生的原因是為了擺脫大量的 if else， 把每個(gè)條件分支做一個(gè)策略類。 具體原理我就不介紹了，不知道的可以 google 一下，網(wǎng)上一堆講設(shè)計(jì)模式的文章，我也講不出什么花來(lái)，我就講在 UI 自動(dòng)化中我們?cè)趺醋觥?舉一個(gè)最簡(jiǎn)單的例子。如下：

在我們的測(cè)試中，大量的 case 都需要經(jīng)過(guò)如下的操作步驟：

• 打開(kāi)瀏覽器

• 登錄

• 進(jìn)入模型 IDE 頁(yè)面

• 創(chuàng)建一個(gè)工程

• 創(chuàng)建一個(gè) DAG

• 在 DAG 頁(yè)面上 build 一個(gè) DAG

• 運(yùn)行 DAG 并等待運(yùn)行結(jié)束

既然大量的 case 都需要執(zhí)行上面的操作，那我們當(dāng)然就希望能做到代碼復(fù)用，所以就寫了一個(gè)方法來(lái)做這個(gè)事情。 但是我們發(fā)現(xiàn)這些步驟中有一個(gè)操作是無(wú)法預(yù)測(cè)的。 也就是如何 Build 一個(gè) DAG， 我們的產(chǎn)品的 DAG 如下

每個(gè) DAG 中都有不同的算子組合在一起，形成一個(gè)圖形。并且每個(gè)算子有它不同的配置。 要在 UI 上 build 一個(gè) DAG 還是需要很多的操作的。 并且 case 之間要 build 的 DAG 的圖形也是不一樣的。 有的 case 需要 5 個(gè)算子組成一個(gè)圖形， 有的 case 可能需要 10 個(gè)算子組成一個(gè)圖形。 這些是完全不一樣的操作， 也就是說(shuō)雖然我們想寫一個(gè)方法來(lái)封裝上面所有的操作。但是其中構(gòu)建 DAG 這一步是我們預(yù)先控制不了也復(fù)用不了的。這怎么辦？ 所以我們索性把 build DAG 的操作定義為一個(gè)接口。 如下：

它只有一個(gè)方法，就是 build()， 意思是這個(gè)方法要實(shí)現(xiàn) build 一個(gè) DAG 的操作。 但具體 build 一個(gè)什么圖形什么配置的 DAG， 由子類自己實(shí)現(xiàn)。
于是我們有了很多固定圖形的 dag 的子類， 他們分別實(shí)現(xiàn)不同的固定圖形的 build 操作。 如下：

于是我們創(chuàng)建這個(gè)可以用來(lái)復(fù)用的方法：

可以看到這個(gè)方法里我們執(zhí)行了上面說(shuō)的所有的步驟，比如打開(kāi)瀏覽器，登錄，跳轉(zhuǎn)頁(yè)面，創(chuàng)建工程等。 但是在 build 一個(gè) dag 的時(shí)候，我們依賴一個(gè) DagBuilder 類型的參數(shù)，也就是我們之前的定義的那個(gè)接口，當(dāng)然這個(gè) dagbuilder 使用了建造者模式，這個(gè)我們之后會(huì)講。 現(xiàn)在我們?cè)?case 中就可以很愉快的使用很少量的代碼完成測(cè)試了。 如下：

當(dāng)然熟悉函數(shù)式編程的同學(xué)會(huì)覺(jué)得這玩意非常眼熟。 實(shí)際上在 java8 中也完全可以使用 lamda 表達(dá)式來(lái)完成 DagBuilder 的構(gòu)造

建造者

這里會(huì)涉及到建造者，策略和工廠三種模式的混合使用?？赡軙?huì)比較啰嗦還請(qǐng)大家耐心看完。

建造者模式和工廠模式都是用來(lái)創(chuàng)建對(duì)象的。 建造者模式適用于一個(gè)對(duì)象的內(nèi)部有特別多的屬性需要外部來(lái)傳遞的情況。 比如在上一個(gè)說(shuō)策略模式的例子中。我們把 Dagbuilder 作為策略類，在 case 調(diào)用的時(shí)候動(dòng)態(tài)傳遞一個(gè)具體的 Dagbuilder 類型決定如何 build 一個(gè) DAG. 那么剛才我們也看到了一個(gè) DAG 是非常復(fù)雜的，里面有不同的圖形， 并且即便圖形固定了， 但是里面的算子的類型和配置可能都會(huì)變化。 比如，按照上面的一個(gè)通用的模型訓(xùn)練的 DAG 圖形， 我們就可以用下面的代碼來(lái)構(gòu)建。

可以看到上面每個(gè)一個(gè) node 的 importToDag 的方法中都會(huì)有兩個(gè) int 類型的數(shù)字參數(shù)。 這個(gè)意思是將算子拖拽到 DAG 中的哪一個(gè)點(diǎn)上。 并且 link 方法用來(lái)連接兩個(gè)算子， build 方法會(huì)執(zhí)行 UI 操作配置當(dāng)前算子。 通過(guò)這樣一段代碼就可以構(gòu)建出上面講策略模式的時(shí)候，截圖中的那個(gè) DAG 圖形。 我們會(huì)發(fā)現(xiàn)非常多的 case 都會(huì)用到這個(gè)圖形。 比如測(cè)試所有的模型訓(xùn)練算法的時(shí)候， 都是走這個(gè) DAG 圖形的。 所以我們理所應(yīng)當(dāng)?shù)臅?huì)想把這個(gè)圖形封裝起來(lái)給很多個(gè) case 使用。 但是雖然 case 使用的圖形一樣，可是每個(gè)算子的配置可能是不一樣的， 而且可能在某一個(gè)節(jié)點(diǎn)上使用的算子都是不一樣的，這需要調(diào)用方動(dòng)態(tài)的傳遞。 所以 builder(建造者) 模式是一個(gè)包含了很多個(gè)零件的對(duì)象， 它封裝了如何操作這些組件創(chuàng)造出最終調(diào)用方想要的東西。但是需要調(diào)用方自由的傳遞這些不同的零件給 builder。 首先我們看看這個(gè) DAG 的 builder 類中定義要使用的零件。

上面是我們構(gòu)建這個(gè)模型訓(xùn)練雙輸入 DAG 所需要的零件。 可以看到由一個(gè)數(shù)據(jù)節(jié)點(diǎn)，一個(gè)數(shù)據(jù)拆分算子，兩個(gè)特征抽取，一個(gè)模型訓(xùn)練，一個(gè)模型預(yù)測(cè)和一個(gè)模型預(yù)估組成。 而且這些零件都分別有 set 方法讓調(diào)用方來(lái)設(shè)置。然后我們就可以在 builder 的 build 方法里使用本節(jié)里一開(kāi)始貼出的代碼來(lái)動(dòng)態(tài)的構(gòu)建圖形了。

策略模式的混用

這里需要注意一點(diǎn)的是，這些零件大部分都是具體的實(shí)體類。 但是有些不是，比如模型訓(xùn)練算法，我們規(guī)定的是一個(gè)抽象類型。 如下：

為什么這么做呢，因?yàn)閷?duì)于所有要測(cè)試模型訓(xùn)練的 case 來(lái)說(shuō)。 圖形是固定的， 某些算法也是固定的。 不論測(cè)試什么模型訓(xùn)練算法，都是一個(gè)數(shù)據(jù)下面連接數(shù)據(jù)拆分算法，再下面連接兩個(gè)特征抽取算法。 也就是說(shuō)對(duì)于模型訓(xùn)練算法來(lái)說(shuō)，這些流程都是固定的，我們實(shí)現(xiàn)就知道該拉取什么樣的算子，只是配置需要調(diào)用方動(dòng)態(tài)傳遞。 但是測(cè)試的時(shí)候我們有各種不同的模型訓(xùn)練算法，這些可不是配置不同，而是連算子都變了， 所以我們把模型訓(xùn)練算法抽象成策略類。我不需要知道到底該拉取哪一個(gè)算子，讓調(diào)用方動(dòng)態(tài)傳遞就好了。 只要它傳遞的是我規(guī)定的策略類型，有規(guī)定的方法來(lái)設(shè)置這個(gè)算子就可以了。

工廠模式的混用

根據(jù)上面的策略模式和建造者模式的混用我們就可以比較方便的構(gòu)建 DAG 圖形給 case 使用了。 但是還是有一點(diǎn)麻煩。那就是一個(gè) builder 需要傳遞的零件太多了。這個(gè)體驗(yàn)有點(diǎn)不友好。 而且我們發(fā)現(xiàn)在大多數(shù)的模型訓(xùn)練測(cè)試場(chǎng)景下，我們只關(guān)心模型訓(xùn)練算法的配置參數(shù)，而不是很在意其他算法的配置是什么樣子的。 這種場(chǎng)景下讓我一個(gè)一個(gè)的去傳遞這些零件還是有點(diǎn)麻煩。 或者說(shuō)在有些情況下，我們是可以動(dòng)態(tài)的推導(dǎo)出其他算子的配置的。 比如我這次要測(cè)試的是邏輯回歸這個(gè)算子。 那么邏輯回歸是一種二分類算子，那么其實(shí)它只能使用二分類的數(shù)據(jù)，特征抽取算法中只能使用二分類的 label 處理， 相應(yīng)的下面也只能連接二分類算子的預(yù)測(cè)和評(píng)估算子。 這些都是我們可以動(dòng)態(tài)推導(dǎo)出來(lái)的。 沒(méi)有必要讓使用者一個(gè)一個(gè)的去傳遞。所以我們?cè)?builder 外面再包一層工廠， 一個(gè)創(chuàng)建 builder 的工廠。如下：

如上圖，根據(jù)傳遞的模型訓(xùn)練算子的類型找到預(yù)先導(dǎo)入的數(shù)據(jù)，配置好特征抽取，推導(dǎo)出所有依賴的算子配置后。 配置好這個(gè) builder 并返回給調(diào)用方。這樣我們通過(guò)之前講的 fastCreateDag 的策略模式的例子。 就可以在 case 中只寫入非常少量的代碼就完成了測(cè)試用例的編寫：

@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("GBDT雙輸入") ? ?@Test ? ?public void doubleInputGBDT(){ ? ? ? ?fastCreateDag(Common.randomString("GBDT2Input"), DagBuilderFactory.getDoubleInputBuilder(new GBDTNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("SVM雙輸入") ? ?@Test ? ?public void doubleInputSVM(){ ? ? ? ?fastCreateDag(Common.randomString("SVM2Input"), DagBuilderFactory.getDoubleInputBuilder(new SVMNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("hetreenet雙輸入") ? ?@Test ? ?public void doubleInputHeTreeNet(){ ? ? ? ?fastCreateDag(Common.randomString("he2Input"), DagBuilderFactory.getDoubleInputBuilder(new HETreeNetNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("gbrt雙輸入") ? ?@Test ? ?public void doubleInputGbrt(){ ? ? ? ?fastCreateDag(Common.randomString("GBRT2Input"), DagBuilderFactory.getDoubleInputBuilder(new GBRTNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("線性回歸雙輸入") ? ?@Test ? ?public void doubleInputLinearRegression(){ ? ? ? ?fastCreateDag(Common.randomString("linearR"), DagBuilderFactory.getDoubleInputBuilder(new LinearRegressionNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("線性分型回歸雙輸入") ? ?@Test ? ?public void doubleInputLFCRegression(){ ? ? ? ?fastCreateDag(Common.randomString("LFCRe"), DagBuilderFactory.getDoubleInputBuilder(new LFCRegressionNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?} ? ?@Features(Feature.ModelIde) ? ?@Stories(Story.LR) ? ?@Description("邏輯回歸多分類雙輸入") ? ?@Test ? ?public void doubleInputLRMultiClass(){ ? ? ? ?fastCreateDag(Common.randomString("LRMulti"), DagBuilderFactory.getDoubleInputBuilder(new LRMultiClassNode())) ? ? ? ? ? ? ? ?.run() ? ? ? ? ? ? ? ?.waitUntil(DagStatus.SUCCESS, 60*20); ? ?}

可以看到上面的每一個(gè)模型訓(xùn)練的 case 的代碼量都非常的少。