Skip to main content

屬性管理 - 製作中

在正式介紹 屬性管理 之前，我們需要先理解屬性為何。

  • 何謂屬性
    屬性是特定對象共同具有的特質或性質，而這些特質在這些對象之間呈現的結果並不會完全一致。

    像是每個人都具有眼睛且眼睛會有顏色，顏色因人而異不會完全相同，身高、體重、膚色、頭髮長度...等等，也是相同的道理，而這些就是身為人共同具有的特質，所以我們可以說每個人都具有眼睛顏色、身高、體重...等等的屬性。

    基於這個概念，GOSU BAR 可以根據不同的需求建立適合的屬性，並運用這些屬性來記錄、管理特定的資訊與資料。

釐清屬性的概念後，接著需要理解 GOSU BAR 屬性的應用對象種類，了解其作用對象的差異以及各自適合使用的情境。

  • 屬性的應用對象（好友／機器人／組織）

    在 GOSU BAR 平台上屬性共分成 3 種應用對象：好友、機器人、組織。
    ※     以層級來說：組織＞機器人＞好友，組織位於最上層（最外），好友位於最下層（最內）。

    ※ 建立在合適的應用對象，有助於管理上的簡化，功能執行的效能、效率也會獲得優化。


    • 好友
      多數情境下屬性的應用對象會選擇好友，因為常見的需求是直接記錄使用者本身的資訊比較多。
      例如：身高、體重、電話、住址、ID，這些都是屬於用戶自己的資訊。

      ※ 註：假設建立了電話、住址、ID 這三個應用對象為好友的屬性，在同一個組織中無論機器人為何，組織中所有的好友都會具備這三個屬性。

    • 機器人
      部分情境下會需要使用應用對象為機器人的屬性，當屬性的資訊內容不屬於用戶個人時，或是代表的是共有的資訊、資料的時候，屬性的應用對象就會選擇為機器人。

      情境：今天要透過聊天機器人舉辦一個有期限的活動，當活動開始時用戶可以觸發活動的相關功能，當活動尚未開始或是活動結束，活動相關功能就必須鎖定不開放使用，且要回應用戶活動尚未開放等訊息。

      要達到這個需求有很多方法，其中一種方法是用屬性來設定 活動開始時間 與 活動結束時間，並透過這兩個時間來判斷活動是否開始或結束，來達到這個需求。

      這時候就出現一個問題，這兩個屬性的應用對象應該選擇 好友 還是 機器人 呢？既然在這邊提出問題，答案顯而易見是要選擇建立在機器人。

      今天這一個活動的開始結束時間的確與用戶自身有關係，但是試想只改機器人的兩個屬性比較容易，還是要對所有用戶的兩個屬性都進行更改比較容易呢？答案很明顯是指改機器人的兩個屬性比較容易，這也是前面提到，應用對象選擇妥當有助於簡化管理難度。

      但是我應該將這兩個屬性的應用對象選擇為好友還是機器人呢？既然在此提出，自然是建立在機器人會最為適合。以屬性設定活動開始時間與活動結束時間的方式來製作，就會有選擇建立在好友與建立在機器人上的差異，但是效率大不相同。

      • 不建議：
        將屬性應用對象建立在好友，並對機器人之下的所有用戶各別設定時間。
        這將增加一些不必要的操作與時間成本，且未來要更改時間也將變得不好維護。
      • 建議：
        將屬性 活動開始時間 建立在機器人，只需要對機器人的這個屬性賦予時間，這個機器人的所有用戶都可以一起共用這個屬性。

    • 組織
      若能理解機器人的說明，那麼建立在組織就不難理解。由於組織的層級比機器人再高一層，所以會將屬性建立在組織的情境，就是當組織之下的所有機器人都需要共用某個屬性，那就會選擇將屬性建立到組織，而非建立到機器人。


無論屬性是建立在哪個應用對象，屬性都有 3 種型態可以選擇。建議依使用情境選擇適當的型態，這將有效優化一些操作，甚至提升運行的效能。

  • 屬性的型態（文字／數字／列表）
    在 GOSU BAR 平台上屬性共分成 3 種型態：文字、數字、列表

    • 文字
      顧名思義，就是專門用來儲存文字的型態。
    • 數字
      專門用來儲存數字的型態，若屬性選擇此種型態，流程中的 設定屬性節點 將出現對此種屬性進行數字 加N 或 減N 的行為，可供選擇。

    • 列表
      若以程式撰寫來理解，列表其實就是陣列，所以能做的操作也相同，流程中的 設定屬性節點，一樣會有專屬於列表的操作行為可供選擇。
  • 屬性管理

 

 

 

 

 

 

Back to top