編輯嚴選

我們對 Null Object 的使用合理嗎？

最近工作上以及私下跟朋友討論時，剛好都遇到了 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）那麼即使 balance 是 nil 的狀況下，也會被當作 #<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? 方法）