---
title: "不該使用 Ruby 的 Class Variable 理由"
date: 2022-01-16T00:00:00+08:00
publishDate: 2022-01-16T22:44:30+08:00
lastmod: 2022-01-17T14:20:52+08:00
tags: ["Ruby","Rails","經驗","程式","筆記"]
toc: true
permalink: "https://blog.aotoki.me/posts/2022/01/16/the-reason-to-avoid-use-class-variable-in-ruby/"
language: "zh-tw"
---


前陣子跟[卡米](https://etrexkuo.medium.com/)聊到一個神奇的 Ruby Class Variable 使用問題，才想起來從使用 [Rubocop](https://github.com/rubocop/rubocop) 之後會自動建議避免使用，就很久沒有使用 Class Variable 這個機制。

在 Ruby on Rails 中依舊還是有一部分實作會使用，因此並不是完全不使用。然而，在大多數的時候我們應該避免使用，除了對這個特性不夠了解之外，也是因為我們通常用不到。

<!--more-->

## 神奇的現象{#unable-eval}

原本是發在 Facebook 社團，然而不知道為什麼一段提及 `.class_eval` 方法的貼文總是被自動偵測刪掉，因此我們先來看一下原始的情況為何。

```ruby
class Counter
  @@count = 0
end

class Counter
  puts @@count
end
# => 0

Counter.class_eval do
  puts @@count
end

# => uninitialized class variable @@count in Object (NameError)
```

在 Ruby 中使用 Open Class 機制和 `.class_eval` 方法應該是等價的情況，然而卻在存取 Class Variable 的時候發生問題。

從錯誤訊息來看，我們會直覺的判斷可能是 [Proc](https://ruby-doc.org/core-3.1.0/Proc.html) 的特性差異，也就是是否為 `lambda` 而影響到變數的查詢，經過一些驗證之後我們基本上可以先排除掉這個可能性。

## Instance Variable 的差異{#different-between-instance-variable}

如果有接觸過其他程式語言，對於 Class Variable 的第一印象會是 `static` 關鍵字，也就是說類似這樣的實作。

```ruby
class Person
  @@type = "Human"

  class << self
    attr_reader :type
  end
end
```

然而，當我們呼叫 `Person.type` 的時候卻不會順利的得到 `Human` 的結果，這是因為對於 Ruby 來說，靜態方法的保存是另外放在 Singleton Class 物件上，而這個物件才是對應到其他程式語言的 `static`（靜態）資訊，實際上正確的實作是這樣。

```ruby
class Person
  @type = 'Human'

  class << self
    attr_reader :type
  end
end
```

對於 `Person` 來說，這些資訊是 Class 定義的 Instance Variable 而非 Ruby 中的 Class Variable 資訊。

## 繼承特性{#inheritance-feature}

在驗證的過程中，我們還發現了一些有趣的情況，像是這樣的實作會順利的讓原本出錯的程式碼能夠正常的運行。

```ruby
@@count = 0

class Counter
  @@count = 0
end

Counter.class_eval do
  puts @@count
end

# => 0
```

然而，當我們嘗試加入一些新的方法時，會發現這個做法有會被互相影響的缺陷。

```ruby
@@count = 0

class Counter
  @@count = 0
end

class Loader
 @@count = 100
end

Counter.class_eval do
  puts @@count
end

# => 100
```

會發生這樣的現象，是因為 Class Variable 的影響範圍是所有「被繼承」的物件，在大多數的網路文章中通常會討論「繼承」的狀況，卻很少討論到這類兩者沒有共同繼承父物件的情況。

原因也很簡單，因為這兩者都屬於 `Object` 這個所有物件的父物件，當我們在 Ruby 程式執行中如果不是在某個 Class 或者 Module 的範圍時，預設的對象就是 `Object` 本身，因此當我們直接呼叫了 `@@count = 0` 的時候就構成了在 `Object` 定義 Class Variable 的條件，進而讓兩個物件得以順利存取。

至於 `.class_eval` 可以順利呼叫的原因，從我們一開始的錯誤訊息會發現，在這個狀況下他會去找的是 `Object` 的 Class Variable 也因此讓條件成立。

## 避免使用{#avoid-to-use}

有經驗的人看到這裡大概已經理解 Class Variable 在 Ruby 中基本上是一個完全不同的概念，因此我們無法以其他語言中的 `static` 特性來看待他，然而在 Ruby 語言的實作上 Class Variable 確實是被視為一個 Class 的 Instance Variable 的，關於從原始碼角度去解析的部分，會留在之後的文章討論。

因為這樣的性質，我們在大部分的情況下都不會需要使用 Class Variable 來解決問題，除了少數像是需要讓繼承的物件「共用」某些特殊資訊的情況才會這樣使用。

舉例來說，我們有一個遊戲伺服器會根據連線類型來切換不同的伺服器實作，很可能會像這樣實作。

```ruby
class Server
  @@connections = []

  def on_connect(connection)
    @@connections << connection
  end
end

class LoginServer < Server
end

class MapServer < Server
end
```

看起來似乎能夠完美的處理連線問題，然而這個設計多少還是會造成耦合以及擴充性的問題，以 DI（Dependency Inject，依賴注入）的角度來看，設計一個物件負責管理可能更加合適。

```ruby
class ConnectionPool
  def initialize
    @connections = []
  end

  def <<(connection)
    @connections << connection
  end
end

class Server
  def initialize(pool)
    @pool = pool
  end

  def on_connect(connection)
    @pool << connection
  end
end
```

像是這樣，我們在未來可以更輕鬆的調整連線管理的方式加入最大人數等等機制，假設連線的協定改變也能夠單純調整 `ConnectionPool` 的封裝而不需要從繼承上下手。

因此，就結論上來說使用 Class Variable 的必要性不大，除非我們找到一個「適合」的情況，大多數時候避免使用會減少更多使用時造成混亂的狀況。