久久天天躁夜夜躁狠狠躁2024,zayou亚洲福利一区

創(chuàng)新互聯(lián)主要從事成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、網(wǎng)頁(yè)設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)羅田,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專(zhuān)業(yè),歡迎來(lái)電咨詢(xún)建站服務(wù):18982081108

過(guò)去19年來(lái)，我(高煥堂)個(gè)人在海峽兩岸、日本、美國(guó)和西班牙等國(guó)擔(dān)任大型框架系統(tǒng)設(shè)計(jì)的實(shí)務(wù)經(jīng)驗(yàn)中，發(fā)現(xiàn)到許多框架開(kāi)發(fā)者擺脫不了「AP開(kāi)發(fā)者」的觀(guān)點(diǎn)：把買(mǎi)主和用戶(hù)視為「大員外」，而開(kāi)發(fā)者變成員外的「長(zhǎng)工」，一切設(shè)計(jì)就以員外的「需求」(Requirements)為依歸。一旦員外需求成維框架設(shè)計(jì)師心中的圣旨，就很可能會(huì)失去本書(shū)不斷強(qiáng)調(diào)的框架API的「主控權(quán)」了。由于A(yíng)P本來(lái)就該緊密跟隨員外的需求，而本來(lái)意圖去「框住」AP行為的框架卻也跟隨著員外需求而跑，那框架就沒(méi)有存在的意義和價(jià)值了。

如何設(shè)計(jì)平臺(tái)框架的<未來(lái)性>

ee ee

歡迎訪(fǎng)問(wèn) ==>高老師的博客網(wǎng)頁(yè)

高煥堂：MISOO(大數(shù)據(jù).大思考)聯(lián)盟.臺(tái)北中心和東京(日本)分社.總教練

EE EE

----過(guò)去19年來(lái)，我(高煥堂)個(gè)人在海峽兩岸、日本、美國(guó)和西班牙等國(guó)擔(dān)任大型框架系統(tǒng)設(shè)計(jì)的實(shí)務(wù)經(jīng)驗(yàn)中，發(fā)現(xiàn)到許多框架開(kāi)發(fā)者擺脫不了「AP開(kāi)發(fā)者」的觀(guān)點(diǎn)：把買(mǎi)主和用戶(hù)視為「大員外」，而開(kāi)發(fā)者變成員外的「長(zhǎng)工」，一切設(shè)計(jì)就以員外的「需求」(Requirements)為依歸。一旦員外需求成維框架設(shè)計(jì)師心中的圣旨，就很可能會(huì)失去本書(shū)不斷強(qiáng)調(diào)的框架API的「主控權(quán)」了。由于A(yíng)P本來(lái)就該緊密跟隨員外的需求，而本來(lái)意圖去「框住」AP行為的框架卻也跟隨著員外需求而跑，那框架就沒(méi)有存在的意義和價(jià)值了。

跟隨著買(mǎi)主和用戶(hù)需求跑，并不是貼近其需求的最佳途徑。譬如說(shuō)，一位完全聽(tīng)從小孩為所欲為的母親，很可能會(huì)寵壞了小孩，所給予的并非小孩的真正需求，因?yàn)樾『?duì)「未來(lái)的」環(huán)境和技術(shù)變化的知識(shí)并不充足，其明示的需求常常偏于眼前視野。無(wú)論是一般的系統(tǒng)架構(gòu)設(shè)計(jì)，或者是軟件框架設(shè)計(jì)，都是關(guān)注于：目前決策的未來(lái)性。例如：

----如果媽媽唯小孩的「需求」是從，每次都答應(yīng)小孩買(mǎi)糖吃，逐漸地媽媽就失控了(框不住了)，再也沒(méi)有替小孩思考未來(lái)的空間，導(dǎo)致目前決策偏于眼前短利，目前決策就失去它的未來(lái)性了?？蚣芑?lèi)就像媽媽?zhuān)珹P子類(lèi)就像小孩。媽媽有責(zé)任要確保整體家庭(或軟件系統(tǒng))的目前決策具有未來(lái)性，以保護(hù)小孩未來(lái)的健康、安全和成長(zhǎng)。

一般的AP開(kāi)發(fā)，是等買(mǎi)主出現(xiàn)了，買(mǎi)主需求明確了，清晰細(xì)述的系統(tǒng)執(zhí)行的未來(lái)情境，然后才開(kāi)始進(jìn)行各項(xiàng)目前決策。由于未來(lái)已經(jīng)被買(mǎi)主和開(kāi)發(fā)者所預(yù)測(cè)好了。目前決策只基于「現(xiàn)實(shí)的目前」需求，或基于「預(yù)測(cè)的未來(lái)」需求，就沒(méi)有未來(lái)性的問(wèn)題了。一般AP開(kāi)發(fā)者，并不需要、也不習(xí)慣于關(guān)注未來(lái)性。

然而，框架設(shè)計(jì)或開(kāi)發(fā)工作，是在「買(mǎi)主來(lái)到」之前就開(kāi)工了。完全依據(jù)開(kāi)發(fā)者所擁有的現(xiàn)實(shí)需求，以及所預(yù)測(cè)的未來(lái)需求，并無(wú)法確保會(huì)滿(mǎn)足未來(lái)多種買(mǎi)主的心意，以及其心意的轉(zhuǎn)變。因此，框架設(shè)計(jì)和開(kāi)發(fā)者，非常需要、也習(xí)慣于關(guān)注未來(lái)性。愈能包容未來(lái)變化的決策，就愈有它的未來(lái)性。因此，在「分析現(xiàn)實(shí)需求」、「預(yù)測(cè)未來(lái)需求」之外，框架設(shè)計(jì)多了一項(xiàng)關(guān)鍵職責(zé)：「包容未來(lái)變化」。這項(xiàng)決策知識(shí)，如下圖所示：

試想餐廳食譜的比喻，點(diǎn)菜單里的選項(xiàng)是餐廳設(shè)計(jì)師所決定的，就如同SurfaceView的SurfaceHolder.Callback接口是由框架設(shè)計(jì)師所決定的。此外，SurfaceHolder本身的接口(如SurfaceHolder.lockCanvas()函數(shù))也是由框架設(shè)計(jì)師所決定的。由于買(mǎi)主還沒(méi)來(lái)，架構(gòu)師只能預(yù)測(cè)買(mǎi)主的需求知識(shí)，可以透過(guò)客戶(hù)調(diào)查而得知這些預(yù)測(cè)性的需求項(xiàng)目，但并不能得到真正的需求內(nèi)涵。就像點(diǎn)菜單上只能憑預(yù)測(cè)而規(guī)劃出一些選項(xiàng)，至于明確的勾選還是要等到買(mǎi)主出現(xiàn)才能定案。這也就是點(diǎn)菜單存在的理由了。

框架設(shè)計(jì)師就依據(jù)上一小節(jié)所述的「包容未來(lái)性」知識(shí)，加上剛才所說(shuō)的「預(yù)測(cè)需求性」知識(shí)，來(lái)得出接口設(shè)計(jì)。如下圖：

這個(gè)接口(API)設(shè)計(jì)本身就是一項(xiàng)關(guān)鍵性的目前決策，當(dāng)架構(gòu)師愈能關(guān)注它的未來(lái)性，該接口就能包容形形×××的買(mǎi)主，也能包容買(mǎi)主的形形×××需求了。能有效實(shí)現(xiàn)上述的未來(lái)性效益者，就稱(chēng)為有效架構(gòu)師。

----為了讓其目前決策能具有好的未來(lái)性，有效架構(gòu)師都很習(xí)慣于「從未來(lái)回顧現(xiàn)在」(Mapping from vision to reality)。蘋(píng)果董事長(zhǎng)賈伯斯(Steve Jobs)說(shuō)過(guò)：“你不可能在眺望未來(lái)時(shí)把生活中的每個(gè)點(diǎn)連接起來(lái)，只有回顧時(shí)能才連點(diǎn)成線(xiàn)”。雖然這聽(tīng)起來(lái)，令人感到有點(diǎn)玄或有些抽象，其實(shí)處處皆能看到實(shí)例。例如，未來(lái)目標(biāo)是：C家送水到S家。目前決策是：如何把水管從S家拉到C家。為了讓未來(lái)目標(biāo)更穩(wěn)當(dāng)可靠(確保未來(lái)S家有水喝)，目前決策必須更能包容未來(lái)的變化(例如C家沒(méi)水了)，提高手段的彈性空間(未來(lái)能調(diào)整拉水管的方式，能將水管拉到B家等)。

Camera照相機(jī)(C家)能透過(guò)鏡頭去取得視像(水)，然后將視像傳遞到SurfaceView窗口(S家)里呈現(xiàn)出來(lái)。為了有效的未來(lái)，目前透過(guò)比較彈性的途徑去將水管拉到對(duì)方。請(qǐng)留意，這里是指拉水管的過(guò)程，不是水實(shí)際流動(dòng)的路徑。愈具有彈性的「拉水管」途徑，愈能在眼前找到最有效的「送水」(即水管)路徑，也愈能在未來(lái)調(diào)整送水的路徑。例如下圖的系統(tǒng)架構(gòu)設(shè)計(jì)，就是缺乏未來(lái)性的：

圖3、少了未來(lái)性的決策：只有食譜而沒(méi)有點(diǎn)菜單

架構(gòu)師(即框架開(kāi)發(fā)者)做了決策：SurfaceView搭配Camera。當(dāng)業(yè)主于稍后出現(xiàn)時(shí)，業(yè)主沒(méi)有選擇的余地，常常不能滿(mǎn)足各業(yè)主的特殊需求，而不想要這個(gè)產(chǎn)品或系統(tǒng)。這表示這個(gè)系統(tǒng)架構(gòu)的設(shè)計(jì)是沒(méi)有未來(lái)性的，沒(méi)有辦法適應(yīng)未來(lái)各種不可預(yù)期的環(huán)境變化(如業(yè)主的不同需求)。

于是，架構(gòu)師將SurfaceView與Camera兩者的相依性(Dependency)降低，成為疏結(jié)合(Loosely Coupled)，預(yù)留了彈性，讓業(yè)主在稍后出現(xiàn)時(shí)，能有決策的空間，并委托AP開(kāi)發(fā)者把其決策寫(xiě)在A(yíng)P子類(lèi)別里。如下圖所示：

圖4、為了創(chuàng)造彈性的決策空間，于是點(diǎn)菜單出現(xiàn)了

----一旦SurfaceView與Camera兩者變成為疏結(jié)合(Loosely Coupled)關(guān)系了，當(dāng)業(yè)主在稍后出現(xiàn)時(shí)，就能做彈性的組合了。例如，委托AP開(kāi)發(fā)者把 SurfaceView聯(lián)接到醫(yī)院加護(hù)病房的儀器設(shè)備上。如下圖所示：

圖5、彈性的決策空間，創(chuàng)造了系統(tǒng)的未來(lái)性

----所以，在A(yíng)ndroid框架的支持下，我們將醫(yī)院加護(hù)病房的儀器聯(lián)結(jié)到護(hù)士站的Android TV(電視機(jī))，讓患者的病情及時(shí)傳送到TV上。同時(shí)，TV也主動(dòng)再將訊息及時(shí)傳送到醫(yī)生的手機(jī)或Pad上，讓醫(yī)生能進(jìn)行實(shí)時(shí)性的決策，提供更高質(zhì)量的服務(wù)。如下圖所示：

----拉霸機(jī)(Slot Machine，簡(jiǎn)稱(chēng)SM)是大家常玩的游戲機(jī)，其造型有許多種，例如Android水果盤(pán)拉霸機(jī)，其畫(huà)面如下圖：

----其玩法是先輸入投注金額(Bet)，然后拉動(dòng)點(diǎn)擊把手或點(diǎn)擊<SPIN>鈕來(lái)轉(zhuǎn)動(dòng)滾動(dòng)條，滾動(dòng)條會(huì)各自轉(zhuǎn)動(dòng)，然后隨機(jī)出現(xiàn)不同圖案，如果停定時(shí)，有出現(xiàn)符合相同或特定相同圖案聯(lián)機(jī)者，即依其賠率而勝出。同一家游戲場(chǎng)里的拉霸機(jī)通常會(huì)聯(lián)網(wǎng)，以投注額厘定累積大獎(jiǎng)(Jackpot)金額，并隨時(shí)更新累績(jī)大獎(jiǎng)金額，以便增加吸引性。這游戲軟件可分為兩部分：

當(dāng)玩家押注后，按下<SPIN> 按鈕(開(kāi)始加速滾動(dòng))，游戲端就將「目前余額」和「押注金額」傳送給GAE的柜臺(tái)端對(duì)象。等待柜臺(tái)端對(duì)象計(jì)算出中獎(jiǎng)金額后，將「新余額」和「獎(jiǎng)項(xiàng)級(jí)別」回傳給Android游戲端(滾動(dòng)開(kāi)始減速)，并更新游戲端的畫(huà)面。其中，Android游戲端對(duì)象(ac01.java)發(fā)送HTTP來(lái)呼叫GAE云層的Servlet接口，如下圖所示：

Android游戲端透過(guò)HTTP和Servlet接口來(lái)傳送三種訊息給GAE 云層。這三種訊息為：

----基于上一小節(jié)所提到的未來(lái)性概念，我們必須將其<游戲機(jī)>端與<云端>兩者的相依性降低，讓兩者之間成為疏結(jié)合(Loosely Coupled)關(guān)系。這樣可以讓業(yè)主有決策的空間：業(yè)主可已決定采用那一種云端服務(wù)。于是，可以畫(huà)出框架需求圖如下：

圖9 設(shè)計(jì)出點(diǎn)菜單，表達(dá)買(mǎi)主(業(yè)主)知識(shí)

----于是，架構(gòu)師將游戲機(jī)端與與云端兩者的相依性降低，成為疏結(jié)合，預(yù)留了彈性，讓業(yè)主在稍后出現(xiàn)時(shí)，能有決策的空間，并委托AP開(kāi)發(fā)者把其決策寫(xiě)在A(yíng)P子類(lèi)別里。如下圖所示：

這個(gè)myGame子類(lèi)別的用途只是將GameEngine(或GameView)的接口傳遞給云端的Game云服務(wù)而已。傳過(guò)去之后，Game云服務(wù)會(huì)主動(dòng)與gameEngine(或GameView) 溝通，取得對(duì)方接口；雙方就相互銜接了。于是，在游戲進(jìn)行期間，GameEngine與Game云服務(wù)之間，是直接互傳訊息(如下注金額和獎(jiǎng)項(xiàng))，并不透過(guò)AP來(lái)傳遞。

為了實(shí)現(xiàn)上述目標(biāo)，就必須讓業(yè)主(委托 AP開(kāi)發(fā)者)把其決策寫(xiě)在A(yíng)P子類(lèi)別里，然后設(shè)計(jì)框架接口(如IGame)來(lái)與框架基類(lèi)(如GameView)相銜接。當(dāng)這個(gè)拉霸機(jī)游戲軟件框架與云端服務(wù)軟件分離了之后，就能將此框架(軟件)與拉霸游戲機(jī)(硬件)兩者整合在一起，成為一項(xiàng)軟硬整合產(chǎn)品了，軟硬件可以一起銷(xiāo)售了。

如果有些業(yè)主(如×××)早已經(jīng)有了云層服務(wù)端了，上述的軟硬整合產(chǎn)品就很容易賣(mài)進(jìn)去。因此EIT框架開(kāi)發(fā)思維，非常有益于軟硬整合產(chǎn)品開(kāi)發(fā)，也非常有助于銷(xiāo)售、開(kāi)拓市場(chǎng)。

預(yù)留空間給業(yè)主做決策是架構(gòu)師的職責(zé)，而應(yīng)該預(yù)留多大的空間，則是架構(gòu)師對(duì)于未來(lái)性的洞悉力和技能了。例如，架構(gòu)師可以決定預(yù)留更大空間，如下圖：

----因?yàn)橐寴I(yè)主挑選或自行設(shè)計(jì)UI，框架就必須將SurfaceView的畫(huà)布(Canvas or Surface)傳遞給AP子類(lèi)別，所以必須修改IGame接口，增添一個(gè)函數(shù)(如setHolder()函數(shù))。如下圖所示：

剛才說(shuō)過(guò)了，架構(gòu)師必須憑借他對(duì)于未來(lái)性的洞悉力和技能，來(lái)決定應(yīng)該如何預(yù)留彈性空間。架構(gòu)師將其所洞悉而得的，簡(jiǎn)明表達(dá)于下<框架需求時(shí)間圖>里。例如，當(dāng)架構(gòu)師洞悉到該替業(yè)主預(yù)留「調(diào)整獎(jiǎng)項(xiàng)」的空間時(shí)，就會(huì)畫(huà)出需求圖，如下圖所示：

----對(duì)于獎(jiǎng)項(xiàng)金額，不同業(yè)主可能有不同的調(diào)整方法或不一樣的計(jì)算公式。也可能同一位業(yè)主，但不同×××需要不同的獎(jiǎng)項(xiàng)調(diào)整公式。此時(shí)，這些不一樣的公式就應(yīng)該撰寫(xiě)在A(yíng)P子類(lèi)別里。而且，框架就必須將云服務(wù)所傳來(lái)的獎(jiǎng)項(xiàng)金額，傳遞給AP子類(lèi)別，依據(jù)調(diào)整公式計(jì)算之后，在回傳給框架基類(lèi)別。這時(shí)必須修改IGame接口，增添一個(gè)函數(shù)(如prizeNotify()函數(shù))。如下圖所示：

Game云服務(wù)先把獎(jiǎng)項(xiàng)傳給GameEngine，此時(shí)GameEngine還不會(huì)立即把獎(jiǎng)項(xiàng)顯示于UI上；而是呼叫IGame接口的prizeNotify()而傳遞給myGaming。

架構(gòu)師的職責(zé)不是對(duì)業(yè)主(或用戶(hù))的未來(lái)行為，進(jìn)行明確的預(yù)測(cè)。架構(gòu)師專(zhuān)注于未來(lái)環(huán)境的變化，創(chuàng)造更好架構(gòu)來(lái)包容未來(lái)環(huán)境的變化。架構(gòu)師要處理的是業(yè)主的未來(lái)行為的「變化」，而不是行為本身。所以架構(gòu)師與開(kāi)發(fā)者的職責(zé)常常是互補(bǔ)的。

框架是軟件架構(gòu)師用來(lái)包容未來(lái)變化的尚方寶劍。架構(gòu)師的洞悉力愈好，規(guī)劃出來(lái)的框架就愈能給業(yè)主高度的決策空間。基于這種優(yōu)越的框架的軟硬件相關(guān)產(chǎn)品，會(huì)具備良好的未來(lái)性，更能掌握美好的商機(jī)?！?/p>

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源：創(chuàng)新互聯(lián)