Go設計模式(2)-面向物件分析與設計-有解無憂

前些日子寫完了第一篇設計模式Go設計模式(1)-語法，本篇文章主要講解遇到專案之后如何做面向物件分析與設計，這篇文章的很多思路都來自于王爭的設計模式之美，不過我會按照自己的經驗和構思來進行講解，

很多同學都看過設計模式相關的書籍，但是經常很難用到實際作業中，其中一個原因可能是沒有想過如何將具體的業務轉化為面向物件的流程，一旦我們熟知這個流程，就能從面向程序思維進入到面向物件思維，然后就可以用學到的設計思想對業務進行設計與優化，

業務

作為一個努力向上的程式員，一天leader告訴你：“為了保證介面呼叫的安全性，我們希望設計實作一個介面呼叫鑒權功能，只有經過認證之后的系統才能呼叫我們的介面，沒有認證過的系統呼叫我們的介面會被拒絕，我希望由你來負責這個任務的開發，爭取盡快上線，”

面向物件分析(OOA)

面向物件分析的產出是詳細的需求描述，

第一輪基礎分析

第一輪分析主要是分析一下具體需求是什么，可以采取什么技術方案解決，

通過和Leader細聊后，發現是自己組維護的后臺系統需要提供幾個API介面供其他組呼叫，這些介面回傳的資料比較敏感，必須做安全校驗，

突然碰到這個問題可能有點懵，可以思考一下有什么方案，如果沒有思路，可以和同事討論一下，也可以看看團隊以前是怎么做的，或者網上搜索一下常規方案是怎樣的，

公司內部常用的API鑒權方案是X5協議，查看網上資訊，一般用簽名方案，

X5協議示例：

appid和appkey

appid和appkey在使用前向管理員申請
appkey僅在計算時使用，如有泄露可隨時更換，

介面傳輸資料$sendData格式定義：

<?php
array(
    'header'=>array(
            'appid'=>$appid,
            'url'=>$url,
            'method'=>$method,
            'sign'=>$sign,
        ),
        'body'=>$body,
);
?>

sign欄位演算法

將appid，對應介面請求報文json串，appkey先后拼接，對其執行32位MD5，之后轉為大寫

$sign=strtoupper(md5($appid.$reqBody.$appkey))

拼接請求報文

將已有引數按如下格式拼接，之后進行base64編碼，即可得到最終的requestbody，

$encRequest=base64_encode(json_encode($reqStream));

根據目前的情況，選擇X5協議實作鑒權，主要是因為這是公司內部協議，每個組都比較熟悉，今后對接、聯調、擴展都相對容易一些，

第二輪分析優化

這一輪需要對技術方案細化，并出流程圖，

一個比較簡單的方案是我們過一下整個流程，然后對流程中的各個細節進行提問，

呼叫方申請appid和appkey
呼叫方使用appid和appkey，計算出sign，并對請求引數進行base64編碼
呼叫方向服務方發送請求
服務方將資料解碼，重新計算sign，判斷sign是否相等

仔細分析流程，我們需要考慮如下幾個問題：

appid和appkey如何申請和存放
- 隨著呼叫方增多，我們需要查看有哪些appid、被分配給哪些組
- appid和appkey方便修改，最好呼叫方和服務方能同時生效
- 是否需要針對不同API設定不同appid和appkey
很多系統或者介面都有鑒權需求
- 如何設計的更加通用，對業務侵入性最低
- 是否需要提供SDK，供其它系統使用
是否需要考慮重放攻擊

這么一想，如果按照最全的方式來做，作業量還是挺大的，鑒于實際情況，我們先完成簡單版，完全版可以等業務量起來時優化，所以對于上面的問題，我們做如下選擇

appid和appkey存放到服務端組態檔中，呼叫方自己維護申請到的appid和appkey，按照系統維度提供appid和appkey，后期可使用配置中心、ETCD或者Redis來管理appid和appkey，
本次只需要要供本系統使用，但設計的需要通用，對服務侵入性要低，后期呼叫方增多后，可提供SDK，
因為都是內網呼叫，相對安全，先不考慮重放攻擊，

流程圖

重點回顧

有時候需求比較抽象、模糊，需要自己去挖掘做取舍，產生清晰、可落地的需求定義，需求分析是一個迭代程序，可以現有一個大體的方案，然后一步一步細化，在這個程序中，可以先列出大體的流程，然后多提問題，多回答這些問題，最后一定要有產出，

說來也有意思，前些日子安排一個同學做了相似的作業，但緊緊是完成任務而已，而沒有去思考通用性、擴展性這些問題，其實也比較容易理解，仿照前人做的東西寫要容易的多，但這樣就很難提升自己的能力和系統架構了，也希望大家今后做專案的時候能夠多思考，

面向物件設計

面向物件設計的產出是類，

劃分職責進而識別出有哪些類

實作這一步，可以根據需求描述，把其中涉及的功能點，一個一個羅列出來，然后再去看哪些功能點職責相近，操作同樣的屬性，可否應該歸為同一個類，

功能點串列：

利用appid和appkey，對請求引數進行加密生成sign
將請求資料進行base64編碼
使用base64對請求資料進行解碼，獲取到appid
從存盤中取出appid對應的appkey
重新計算sign，判斷兩個sign是否匹配

1、5和sign有關，2、3和編碼、決議有關，4和存盤有關，所以可以粗略得到三個核心類，AuthToken、ApiRequest、CredentialStorage，AuthToken負責實作1、5這兩個操作;ApiRequest負責2、3兩個操作;CredentialStorage負責4這個操作，

當然，這是一個初步的類的劃分，其他一些不重要的、邊邊角角的類，我們可能暫時沒法一下子想全，但這也沒關系，面向物件分析、設計、編程本來就是一個回圈迭代、不斷優化的程序，

定義類及其屬性和方法

對于方法的識別，識別出需求描述中的動詞，作為候選的方法，再進一步過濾篩選，對于屬性的識別，把功能點中涉及的名詞，作為候選屬性，然后同樣進行過濾篩選，

現在我們來看下，每個類都有哪些屬性和方法，我們還是從功能點串列中挖掘，

AuthToken

AuthToken類相關的功能點有兩個：

利用appid和appkey，對請求引數進行加密生成sign
判斷兩個sign是否匹配

動詞有：生成、匹配

名詞有：sign（appid和appkey從業務上來說不屬于AuthToken，可以當做引數傳入)

type Header struct {
	AppId string
	Sign  string
}
type Data struct {
	Header Header
	Body   string
}

type AuthToken struct {
	sign string
}

func CreateAuthToken() *AuthToken {
	return &AuthToken{}
}

func (authToken *AuthToken) Create(appId string, appKey string, body string) string {
	h := md5.New()
	h.Write([]byte(appId + body + appKey))
	authToken.sign = strings.ToUpper(fmt.Sprintf("%x", h.Sum(nil)))
	return authToken.sign
}

func (authToken *AuthToken) Match(token *AuthToken) bool {
	if authToken.sign == token.sign {
		return true
	}
	return false
}

ApiRequest

ApiRequest類相關功能點有兩個：

進行base64編碼，生成請求資料
進行base64解碼，獲取appid和sign

動詞有：編碼、解碼

type ApiRequest struct {
	appId string
	sign  string
	data  *Data
}

func CreateApiRequest() *ApiRequest {
	return &ApiRequest{}
}
func (apiRequest *ApiRequest) Encode(data string) string {
	return base64.StdEncoding.EncodeToString([]byte(data))
}
func (apiRequest *ApiRequest) Decode(data string) (appId string, sign string, err error) {
	bytes, err := base64.StdEncoding.DecodeString(data)
	if err != nil {
		return
	}
	apiRequest.data = &Data{}
	if err := json.Unmarshal(bytes, apiRequest.data); err != nil {
		return "", "", err
	}
	apiRequest.appId = apiRequest.data.Header.AppId
	apiRequest.sign = apiRequest.data.Header.Sign
	return apiRequest.appId, apiRequest.sign, nil
}

func (apiRequest *ApiRequest) GetAppid() string {
	return apiRequest.appId
}

func (apiRequest *ApiRequest) GetSign() string {
	return apiRequest.sign
}

CredentialStorage

CredentialStorage相關功能點只有一個：

從存盤中取出appid對應的appkey

因為后期獲取資料位置會變，所以最好設計為介面，基于介面而非具體的實作編程，

type CredentialStorage interface {
	GetAppkeyByAppid(appId string) string
}

type CredentialStorageConfig struct {
}

func (config *CredentialStorageConfig) GetAppkeyByAppid(appId string) string {
	if appId == "test" {
		return "test"
	}
	return "test"
}

定義類與類之間的互動關系

類之間的互動關系可以簡化為四種：泛化、實作、組合、依賴

泛化：可以理解為繼承關系

實作：一般指介面實作類之間的關系

組合：包括聚合、組合、關聯等，一般指類中包含其它類

依賴：只要兩個類有任何關系，就認為是依賴關系

所以CredentialStorage和CredentialStorageConfig是實作關系，

將類組裝起來并提供執行入口

接下來我們需要將類組裝起來，讓整個代碼跑起來，

我們封裝所有的實作細節，設計了一個最頂層的ApiAuthencator類，暴露一組給外部呼叫者使用的API介面，作為觸發執行鑒權邏輯的入口，

type ApiAuthencator struct {
	credentialStorage CredentialStorage
}

func CreateApiAuthenCator(cs CredentialStorage) *ApiAuthencator {
	return &ApiAuthencator{credentialStorage: cs}
}

func (apiAuthencator *ApiAuthencator) Auth(data string) (bool, error) {
	//1.決議資料
	apiRequest := CreateApiRequest()
	appId, sign, err := apiRequest.Decode(data)
	//fmt.Println(appId, sign, apiRequest.data)
	if err != nil {
		return false, fmt.Errorf("Decode failed")
	}
	//2.獲取appId對應的appkey
	appKey := apiAuthencator.credentialStorage.GetAppkeyByAppid(appId)
	//3.重新計算sign
	authToken := CreateAuthToken()
	newSign := authToken.Create(appId, appKey, apiRequest.data.Body)
	if sign == newSign {
		return true, nil
	}
	return false, nil
}

面向物件編程

面向物件設計完成之后，我們已經定義清晰了類、屬性、方法、類之間的互動，并且將所有的類組裝起來，提供了統一的執行入口，接下來，面向物件編程的作業，就是將這些設計思路翻譯成代碼實作，

在面向物件分析的時候，會完成部分編碼作業，面向物件編程程序中需要將代碼進行完善，不過因為這個業務相對簡單，所以現在只寫一下main函式，看一下執行效果，

func main() {
   //客戶端
   appId := "test"
   appKey := "test"
   sendData := &Data{
      Header: Header{
         AppId: appId,
      },
      Body: "for test",
   }
   authToken := CreateAuthToken()
   sign := authToken.Create(appId, appKey, sendData.Body)
   sendData.Header.Sign = sign
   sendDataMarshal, _ := json.Marshal(sendData)
   sendDataString := CreateApiRequest().Encode(string(sendDataMarshal))
   //fmt.Println(sign, sendData, string(sendDataMarshal), string(sendDataString))

   //服務端
   apiAuthenCator := CreateApiAuthenCator(new(CredentialStorageConfig))
   auth, err := apiAuthenCator.Auth(sendDataString)
   if err != nil {
      fmt.Println(err.Error())
      return
   }
   if auth == false {
      fmt.Println("auth failed")
      return
   }
   fmt.Println("auth success")
   return
}