編輯嚴選
我們對 Null Object 的使用合理嗎?

閱讀時間約 14 分鐘

最近工作上以及私下跟朋友討論時,剛好都遇到了 Null(不存在)類型的處理,通常我不會特別去在意這件事情,然而近年讀了一些關於 Null 的文章後(如:The worst mistake of computer science)對於這件事情的看法有不少改觀。

是「沒有」還是「空的」

相信很多人都看過 0 vs null 這張迷因圖,如果衛生紙用完了是「空的(Empty)」狀態,如果一開始就沒有衛生紙,那就是「沒有(Null)」的情境。

然而在中文上的翻譯,我們通常用來描述 Null 的情境,那就讓「空的」和「空值」看起來非常相似,在維基百科 - 空值(SQL)上的描述則是用「空值(Null)」和「零值(0)」來區分,還是非常類似的。

尤其在 Ruby、JavaScript 這類語言,想要區分出「不存在」跟「沒有」的使用情境,通常會更加困難,如果是 Golang、C#、Java 這類語言,因為型別檢查的關係是不會有這樣的情境發生。

如果在 Golang 中給定一個欄位 age 型別為 int 那麼預設就會是 0 而不會是 Null 在 Ruby 中則會因為不知道型別,那麼就會維持「不存在」的狀況,自然變成「沒有」

大多是空的

實務上來說,我們在軟體開發遇到的大多數情況都會是 Empty 的狀況,雖然會出現 Null 的情境,主要還是在找不到資料這類狀況為主,通常我們想處理的都是 Empty 的狀況。

舉個案例,近期有人跟我討論 ESLint 的警告問題,其中一個是 TypeScript 的實作。

type TimeLeft = {
hours?: number;
minutes?: number;
seconds?: number;
}
// ...

const Countdown = ({ expiredTime }) => {
var timeLeft = {}
calculateTimeLeft(timeLeft, expiredTime)
// ...

return (<>
<Text>{{ timeLeft.hours || 0 }}</Text> // 這裡被警告
<Text>{{ timeLeft.minutes || 0 }}</Text> // 這裡被警告
<Text>{{ timeLeft.seconds || 0 }}</Text> // 這裡被警告
</>)
}

當我們在處理這個狀況時,我們讓他保持「沒有」的狀態直到實際使用,那麼就需要在每一個地方「檢查是否存在」然後再賦予預設值。

然而,預設值不應該是在物件初始化階段就定義好的嗎?因此實際上應該這樣做。

type TimeLeft = {
hours: number;
minutes: number;
seconds: number;
}

const newEmptyTimeLeft = (): TimeLeft => { hours: 0, minutes: 0, seconds: 0}

// ...
const calculateTimeLeft = (expiredTime: Date): TimeLeft {
var timeLeft = newEmptyTimeLeft()
// ...
return timeLeft
}

const Countdown = ({ expiredTime }) => {
const timeLeft = calculateTimeLeft(timeLeft, expiredTime)
// ...

return (<>
<Text>{{ timeLeft.hours }}</Text>
<Text>{{ timeLeft.minutes }}</Text>
<Text>{{ timeLeft.seconds }}</Text>
</>)
}

在真實的開發情境裡面,有不少地方是可以這樣調整去消除掉 Null 的情況,我們需要的通常是一個預設值。

哪裡有 NULL

我們以 Domain-Driven Design(領域驅動設計)的 Domain Model(領域模型)來來看,其中 Entity(實體)就是一個會有 Null 情況的物件類型。

首先,Entity 的定義上通常會具備一個 Identity(識別,或者說 ID)來表示這是一個獨立個體,假設有一個「使用者」的概念存在於一個以 Rails 開發的系統,我們通常會定義一個 Model 如下。

class User < ApplicationRecord
# attribute :id, type: :integer
# attribute :name, type: :name
# attribute :age, type: :integer

# ...
end

在 Ruby on Rails 中我們要找到一個使用者,可以像這樣進行查詢。

class ProfileController < ApplicatonController
def show
@user = User.find_by(id: params[:id])
end
end

在上述的程式碼中,當我們找不到某個 ID 的使用者時,就會得到 Null 的結果。然而,這樣的寫法很容易讓後續的程式出錯,最後需要大量的 if @user 判斷式來檢查是否有資料。

因此,更多會採用這樣的做法。

class ProfileController < ApplicatonController
def show
@user = User.find(params[:id])
rescue ActiveRecord::RecordNotFound
render :user_not_found
end
end

如果找不到,對 Rails 來說是一種「錯誤(Error)」的情境,因此會拋出 ActiveRecord::RecordNotFound 的訊息,我們還能善加利用,顯示出找不到使用者的畫面。

那麼,如果是 Null Object 的情境又會是如何呢?

class ProfileController < ApplicatonController
def show
@user = User.find_or_initialize_by(id: params[:id]) do |user|
user.name = 'Guest'
end
end
end

在 Rails 還提供了 #find_or_initialize_by 的方法,當遇到 Null 的狀況時,產生一個新的 User 物件並且設定預設值。

這樣的寫法似乎還是有點不夠優雅,因為在 Rails 中我們可以對資料庫欄位設定預設值,或者利用 attribute 的 DSL(領域特定語言)來設定預設值,那麼在大多數的狀況下只需要使用 #find_or_initialize_by 幾乎就涵蓋大多情境。

從概念上來反推,會發生 Null 的情境主要是我們想去尋找某個「實際存在的物體(Entity,實體)」卻因為實際不存在而找不到。

然而,如果是某個實體上的數值(Value)大多是可以存在預設值的,像是 User 身上的 name 或者 age 都可以給定預設的數值,如果是一個複雜的物件,也能夠利用 Value Object(數值物件)的方式處理。

class User < ApplicationRecord
# attribute :id, type: :integer
# attribute :name, type: :name
# attribute :age, type: :integer

composed_of :balance, class_name: 'Money', mapping: %w(balance amount)
end

# app/models/money.rb
class Money
attr_reader :amount, :currency

def initialize(amount, currency = :TWD)
@amount = amount || 0
@currenncy = currency
end

# ...
end

以上面的例子來看,使用者身上的 balance 欄位是一種 Money(金錢)的概念,會轉換成一個 Value Object 來處理,這個 Moeny 物件身上也會預設特定的幣種(Currency)那麼即使 balancenil 的狀況下,也會被當作 #<Money amount=0, currency=:TWD> 的方式操作,就能避免需要使用 if @user.balance 的判斷情境,因為對於一個數值來說具有「預設值」比「不存在」更加合理(或者說更常見)

Null Object 的應用

從前面針對 Empty、Null 兩種情境的說明,大致上可以看出來 Null Object 有點類似「預設值」的感覺,當我們找不到某個實體的時候,給予一個預設的行為,而且很高的機率是不做任何事情。

從維基百科對 Null Object Pattern 的介紹來看,最早是使用 Void Value 來描述這種物件,是不是跟某個數值不存在時,給予一個「預設數值」的意思非常接近。

假設大多數情境都是對「找不到」做備援,那麼我們更應該思考的是「預設值」的設定,如果不應該有預設值,那應該要設計為建立某個實體的必填欄位,進而確保我們的行為是一致的。

以最近工作上的例子,我們原本設計 tags 在沒有任何資料時,會在 API 回應中不回傳這個欄位,那麼在使用者端呼叫時,就需要這樣處理。

@status = @api.status_of(params[:report_id])

if @status.tags.present?
@status.tags.each do |tag|
# ...
end
end

然而,我們實際上是可以給 [] 做為預設值的,那麼實作上就會變成

@status = @api.status_of(params[:report_id])

@status.tags.each do |tag|
# ...
end

這樣讓使用者端更簡潔,並且能夠減少多餘的判斷,因為我們將判斷的邏輯隱含到了提取陣列元素的程式語言底層中,並且具有相同的意義。

另一方面,我們還有一個 score 的數值確實有可能不存在,那麼該如何處理呢?因為實作上使用 Golang 來實現,可以參考一下 Golang 的 database/sql 做了怎樣的處理。

type NullString struct {
String string
Valid bool
}

對 Golang 來說,是不能有 Null 的數值存在的,除非他是一個指標(Pointer)指向一個沒有數值的位址(跟 Entity 的 ID 找不到對應的物件概念相同)但是在資料庫中存在著 Null 的概念,因此對應的方式就是用 Valid(正確)來表示是否存在資料,這剛好就是一種 Null Object 或者 Value Object 的變體。

也因此,我們可以將 API 的回傳設計成這樣。

{
"id": 1,
"score": {
"value": 0,
"verified": false
},
"tags": []
}

在使用端,我們可以設計一個 Value Object 叫做 Score 來處理。

class Score
attr_reader :value, :verified

def initialize(value, verified=false)
@value = value
@verified = verified
end

def allowed?(score)
@verified && @value > score.value
end

# ...
end

像這樣,我們就可以直接把 Null Object 要做的預設行為隱含在 Value Object 中,再做各種不同類型處理的時候就可以不用做額外的判斷,像是下面這樣使用。

@status = @api.status_of(params[:report_id])

return upload if @status.allowed?(UPLOAD_SCORE)
return refresh_later unless @status.valid?

# others ...

這樣一來,程式中就可以減少很多 Null 類型的檢查,也符合 Null Object 設計的目的。

在 Rails 裡面經常遇到字串可能是 "" 或者 nil(Null) 的情況,因此在 ActiveSupport 對 Ruby 做的擴充,還有一個叫做 #blank? 的方法,會檢查 "" 或者 nil 來回傳 true,然而如果能保證不會有 nil 的狀況出現,使用 Ruby 內建的 #empty? 方法即可(nil 在 Ruby 是物件,但沒有 #empty? 方法)
53會員
40內容數
軟體工程師逐漸變成一個熱門的職業,當我們進入這個職業之後應該要具備怎樣的技能才會在工作上更加順利呢?這系列的專欄會分享日常工作中的經驗以及一些案例分析,讓我們一起努力成為一位更優秀的軟體工程師吧!
留言0
查看全部
發表第一個留言支持創作者!
蒼時弦也的沙龍 的其他內容
LeSS in Action - 壞味道
閱讀時間約 1 分鐘
LeSS in Action - 重構
閱讀時間約 1 分鐘
LeSS in Action - 產品與專案
閱讀時間約 1 分鐘
LeSS in Action - 後記
閱讀時間約 1 分鐘
代號 220707,幽魂,博物館
閱讀時間約 3 分鐘
你可能也想看
【 讓我們對話吧 】由産経新聞社發行的免費雜誌「metropolitana(メトロポリターナ)」為了推廣女性身心關懷活動「Fem Care Project」,在6月20日於産経新聞刊登全版報紙廣告,但是製作非常用心且有創意,請你打開來先看一次,然後把報紙摺起來再看一次,原本的對話會變成不同的字句。
Thumbnail
avatar
Lee Genesis
2023-06-27
我們對性騷擾加害人保護得太好了!(修訂版)扼要提示性騷擾加害人所享受的保護,從而肆無忌憚
avatar
葉大哥
2023-06-05
Rethinking Museums:我們對兒童與家庭觀眾是否足夠友善呢?平衡報導.....英國慈善組織「Kids in Museums」針對英國國民信託管理的女神雕像,發現被塗上藍色蠟筆一事所做的發言,值得深思。 「許多家庭觀眾不參觀博物館,就是憂慮自己行為舉止應該如何表現,以及他人對自己行為的評判。而這些故事與周遭的責備文化,不論是責備家長、兒童或博物館工作人員,都
Thumbnail
avatar
布麗姬的新博物館學
2023-05-04
我们对”速度“上瘾了你有没有过这样的经历,当自己必须专注在做某样事情上,手却情不自禁地想要去拿手机,刷一刷社交媒体,然后几分钟后,又再度把注意力拉回到正在做的事情上,不断地重复又重复?
Thumbnail
avatar
阿仪的烦恼
2023-03-17
我們對整體編程,就是我們的目的?我們對「整體」(也稱「一體」)進行編程。這就是我們的目的。我們不知道這一點。我們已經夠虛榮的了,如果我們真的知道,那就真的很噁心了。我們在這些「車輛」中沒有裝備,無法真正行使那種控制權,但我們有幾何能力達到這個目的,而且我們現在有必要瞭解這一點。
Thumbnail
avatar
守候正確邀請的PROJECTOR
2022-12-27
我們對人的理解不該只用性別|男性脆弱的情感面我:「你覺得男女有什麼差異嗎?」朋友「被社會期待的東西不同吧!」 對男性的成長,自尊成為了所有脆弱的防護罩,在男性的社群中,沒有示弱、沒有眼淚,男人們被期待成為一個獨立自主樣子。 這篇無意挑起任何性別戰爭,更期待的是一個彼此傾聽的機會。
Thumbnail
avatar
你的人生好夥伴 昆陽
2022-09-03
我們對哲學教育的期待是什麼?這些期待有問題嗎?臺灣近年來吹起的哲學教育風潮下,我們需要問問自己期待哲學教育能為我們帶來什麼。 而這些期待又是否是哲學教育確實可以兌現的承諾,他能做到什麼、而他的極限又在哪?
Thumbnail
avatar
Wen Tao Chen
2021-06-09
我們對科學的無上推崇是真理還是迷信?自由人文讀書會《偽理性》系列現代人對科學無比的信任與崇尚,甚至人們對科學的崇拜已經有些偏離了科學原初的精神,成為一種迷信。 我們認為科學追求的是「事實」,也只關心事實,然而這樣只重視事實的信念,當它成為判斷價值的唯一標準時,就造成了一些問題。首先我們需要理解人不只會關心「事實」,也會在乎「意義」。 追尋意義可說是人深層的內在需
Thumbnail
avatar
學習者向前走
2021-05-02
我們對檢舉達人「雙標」?你有聽過「告訴乃論」嗎?(文字+音檔16:15)我認同這個說法,但我認為「雙標」(雙重標準)是人性
Thumbnail
avatar
王大明
2021-01-19
「我們對這個世界的認識,只不過是隔靴搔癢。」—《異鄉人》卡繆「Is it just me, or is it getting crazier out there?」—《JOKER》 小丑在笑,不代表開心;莫梭沒哭,不代表無情,但因為不符合社會期待,被視作異類。然而,透過卡繆的筆,我們可以窺探莫梭的內心,得以比較出外在世界多麽荒謬。
Thumbnail
avatar
Krachreading
2020-07-01