轉型 | 平屋慢生活

Code

有一塊碎石，曾在河岸邊靜靜沉睡百年。它堅硬、粗糙、不懂流動。直到有一天，一條溪水與它擦身而過。

「你怎麼總是不動？」水問。

「我就是這樣被造的，不像你，總能輕盈地轉彎、改道。」碎石低聲說。

「但你知道嗎？」水輕聲笑道，「我之所以能走那麼遠，不是因為我比你強，而是我願意轉。」

碎石沉默良久，忽然覺得，那句話像是一道光，悄悄劃過它堅硬的內裡。它開始想：如果有一天，我也能在某個時刻學會轉型 —— 也許，我也能成為某種形式的流動看看這個世界更多的樣貌。

在程式的語法中，我們見證數字從一種型態變成另一種形態、物件從一個面貌蛻變為更適配的角色。這些「轉型」，看似只是語法上的操作，實則承載著如何讓資料順勢而生、應需而變的深意。

而我們，是否也能從中學會，如何在對的時機，捨去執念、跨越邊界？
如何在堅固與柔軟之間，找到最合宜的模樣？

🌺 隱含轉型 (Implicit Casting)

商業情境

一個電子商務網站的購物車系統。你需要計算訂單的總金額。商品數量是整數 (int)，但商品單價可能是小數 (decimal，用於金融計算更精確)。在計算總價時，整數會被自動轉換為小數類型。

public class ShoppingCart
{
    public decimal CalculateSubtotal(int quantity, decimal unitPrice)
    {
        // 在這裡，'quantity' (int) 在與 'unitPrice' (decimal) 相乘之前，
        // 會被「隱含轉型」為 decimal 型別。
        // 這是安全的，因為 int 可以完全無損地表示為 decimal。
        decimal subtotal = quantity * unitPrice;

        Console.WriteLine($"計算過程：{quantity}(int) * {unitPrice}(decimal) = {subtotal}(decimal)");
        
        return subtotal;
    }
}

// 使用範例
var cart = new ShoppingCart();
decimal total = cart.CalculateSubtotal(5, 19.99m); // m 代表 decimal 字面值
// 輸出: 計算過程：5(int) * 19.99(decimal) = 99.95(decimal)

為何發生

C# 的運算規則要求參與運算的兩個數值必須是相同類型。當類型不同時，編譯器會嘗試將「範圍較小」或「精度較低」的型別自動提升到「範圍較大」或「精度較高」的型別，這個過程就是隱含轉型。

解決方案

在這種情況下，隱含轉型本身就是「解決方案」，它讓程式碼更簡潔易讀。開發者不需要手動寫 (decimal)quantity。理解這個機制即可。當你在進行混合型別運算時，要確保接收結果的變數（如此處的 subtotal）使用了範圍足夠大的型別（decimal），以避免潛在的資料溢位或精度損失。

🌺 明確轉型 (Explicit Casting)

商業情境

一個學生成績管理系統。系統計算出的平均分是帶有小數的 double 型別（例如 88.7 分）。但在最終的儀表板或報表上，產品經理要求只顯示整數部分（例如 88 分），捨去小數。

public class GradeReport
{
    public int GetDisplayScore(double averageScore)
    {
        // 業務需求是直接捨去小數，不是四捨五入。
        // 因此，我們需要「明確轉型」將 double 轉為 int。
        // 這個轉型可能會遺失資料（小數部分），所以必須明確告知編譯器。
        int displayScore = (int)averageScore;      
        Console.WriteLine($"原始平均分: {averageScore}, 顯示分數: {displayScore}");    
        return displayScore;
    }
}

// 使用範例
var report = new GradeReport();
report.GetDisplayScore(88.7); // 輸出: 原始平均分: 88.7, 顯示分數: 88
report.GetDisplayScore(99.2); // 輸出: 原始平均分: 99.2, 顯示分數: 99

為何發生

我們需要將一個高精度/大範圍的型別 (double) 存入一個低精度/小範圍的型別 (int)。

解決方案

編譯器無法保證這個過程是安全的，所以它要求開發者使用 (int) 語法來「簽署」這個有風險的操作。
因此明確轉型 (int) 就是這裡的解決方案。

在做明確轉型前，務必清楚業務需求。是捨去 ((int))、四捨五入 (Math.Round())、無條件進位 (Math.Ceiling()) 還是無條件捨去 (Math.Floor())？使用最符合語意的函式通常比直接轉型更好。

如果轉換的來源（如 long）可能超出目標（int）的範圍，應使用 checked 關鍵字來拋出溢位例外，或在轉換前進行範圍檢查。

🌺 向上轉型 (Upcasting) - 參考型別

商業情境

一個文件處理系統，可以處理多種類型的文件，如 PdfDocument、WordDocument 和 ImageFile。儘管它們的具體操作不同，但它們都有一個共同的行為：「儲存」。我們可以定義一個 IStorable 介面，讓所有文件類別都去實作它。這樣我們就可以將所有待處理的文件放在一個共同的列表中。

// 定義共同行為的介面
public interface IStorable { void Save(); }

// 實作介面的具體類別
public class PdfDocument : IStorable { public void Save() => Console.WriteLine("儲存 PDF 文件..."); }
public class WordDocument : IStorable { public void Save() => Console.WriteLine("儲存 Word 文件..."); }
public class ImageFile : IStorable { public void Save() => Console.WriteLine("儲存圖片檔案..."); }

public class DocumentProcessor
{
    public void SaveAll(List<IStorable> documents)
    {
        foreach (var doc in documents)
        {
            // 我們不在乎 doc 的具體類型是 Pdf, Word 還是 Image
            // 我們只知道它一定有 Save() 方法，因為它符合 IStorable 契約
            doc.Save();
        }
    }
}

// 使用範例
var processor = new DocumentProcessor();
var docsToSave = new List<IStorable>
{
    new PdfDocument(),  // 將 PdfDocument 實例「向上轉型」為 IStorable
    new WordDocument(), // 將 WordDocument 實例「向上轉型」為 IStorable
    new ImageFile()     // 將 ImageFile 實例「向上轉型」為 IStorable
};
processor.SaveAll(docsToSave);

為何發生

這是物件導向程式設計（OOP）中多型（Polymorphism）的核心。當我們將子類別（PdfDocument）的實例賦值給父類別或介面（IStorable）的變數時，就發生了向上轉型。這是絕對安全的，因為子類別保證擁有父類別或介面的所有成員。

解決方案

這是一種設計模式，而非一個「問題」。利用向上轉型可以寫出更通用、更具擴充性的程式碼。當未來需要新增 ExcelDocument 時，只需讓它實作 IStorable，現有的 SaveAll 方法完全不需要修改。

🌺 向下轉型 (Downcasting) - 參考型別

商業情境

延續上面的文件處理系統。假設只有 PdfDocument 有一個特殊的方法 AddEncryption()。現在，在處理文件列表時，我們需要判斷如果文件是 PDF，就為它加上加密。

// 擴充 PdfDocument
public class PdfDocument : IStorable 
{
    public void Save() => Console.WriteLine("儲存 PDF 文件...");
    public void AddEncryption() => Console.WriteLine("為 PDF 文件新增加密！"); 
}

public class DocumentProcessor
{
    public void ProcessSpecialFeatures(List<IStorable> documents)
    {
        foreach (var doc in documents)
        {
            doc.Save(); // 所有文件都能 Save

            // 現在需要使用 PdfDocument 的專有功能
            // 必須「向下轉型」才能存取 AddEncryption()
            // **不安全的方式，可能拋出例外**
            // if (doc is PdfDocument) {
            //     PdfDocument pdf = (PdfDocument)doc; // 明確轉型
            //     pdf.AddEncryption();
            // }

            // **更安全、更推薦的方式 (使用 as 運算子)**
            PdfDocument pdf = doc as PdfDocument;
            if (pdf != null)
            {
                // 轉型成功，pdf 不是 null
                pdf.AddEncryption();
            }
        }
    }
}

為何發生

變數 doc 的編譯時期型別是 IStorable，它並不知道 AddEncryption() 這個方法的存在。
我們需要告訴編譯器：「我相信這個 doc 的實際執行時期型別是 PdfDocument，請把它轉回來，讓我能用它的特殊功能。」
風險是，如果 doc 的實際型別是 WordDocument，使用 (PdfDocument)doc 會在執行階段拋出 InvalidCastException 錯誤，導致程式崩潰。

解決方案

通常不要在沒有檢查的情況下進行向下轉型。

is 關鍵字：先用 if (doc is PdfDocument) 檢查，再轉型。安全，但有兩次型別檢查（一次 is，一次轉型），效能稍差。
as 運算子（推薦）：使用 doc as PdfDocument。如果轉型成功，它會返回轉換後的物件；如果失敗，它會返回 null 而不是拋出例外。接著只需檢查是否為 null 即可。這是最常用且優雅的方式。

🌺 Boxing (裝箱) 與 Unboxing (拆箱)

商業情境 1

一個比較舊的快取系統（或需要與不支援泛型的舊版 API 互動），它使用 System.Collections.Hashtable 來儲存各種設定，其中 Key 是字串，但 Value 是 object，可以存放任何東西。現在我們要存入一個「重試次數」（int），之後再取出來使用。

using System.Collections;

public class LegacyCache
{
    private Hashtable cache = new Hashtable();

    public void SetRetryCount(int count)
    {
        // 將 int (實值型別) 存入需要 object (參考型別) 的地方
        // 這裡發生了「Boxing」
        // 1. 在堆積(Heap)上配置一個物件
        // 2. 將 count 的值複製進去
        cache["RetryCount"] = count;
        Console.WriteLine($"值 {count} 被裝箱(Boxed)並存入快取。");
    }

    public int GetRetryCount()
    {
        // 從快取中取出 object
        object cachedValue = cache["RetryCount"];

        // 將 object (參考型別) 轉回 int (實值型別)
        // 這裡發生了「Unboxing」
        // 1. 檢查物件是否為已裝箱的 int
        // 2. 將值從堆積複製回堆疊上的變數
        int retryCount = (int)cachedValue;
        
        Console.WriteLine($"值 {retryCount} 從快取中被拆箱(Unboxed)。");
        return retryCount;
    }
}

// 使用範例
var legacyCache = new LegacyCache();
legacyCache.SetRetryCount(5);       // Boxing
int retries = legacyCache.GetRetryCount(); // Unboxing
Console.WriteLine($"拿到的重試次數: {retries}");

為何發生

當實值型別（如 int, double, struct）需要被當作參考型別（object）使用時，就會發生 Boxing。
這在非泛型集合（如 ArrayList, Hashtable）和某些方法簽章（如 Console.WriteLine(object value)）中很常見。Unboxing 則是其逆過程。
問題在於 Boxing 和 Unboxing 會帶來效能開銷。

Boxing 需要在 Heap 上分配記憶體並進行資料複製
Unboxing 需要進行型別檢查和資料複製。在頻繁發生的迴圈中，這會對效能產生顯著影響。

解決方案

通常會優先使用 Generics 解決這個問題!
用 List 取代 ArrayList，用 Dictionary<TKey, TValue> 取代 Hashtable。

// 使用泛型，完全避免 Boxing/Unboxing
private Dictionary<string, int> modernCache = new Dictionary<string, int>();

public void SetRetryCount(int count)
{
    modernCache["RetryCount"] = count; // 沒有 Boxing
}

public int GetRetryCount()
{
    return modernCache["RetryCount"]; // 沒有 Unboxing
}

泛型讓我們在編譯時期就確定型別，不僅避免了 Boxing/Unboxing 的效能損耗，還提供了型別安全，防止存入錯誤類型的資料。只有在無法使用泛型（如與舊版程式庫互動、反射等）時，才需要處理 Boxing/Unboxing。

商業情境 2 快取或屬性容器

你需要一個類別來儲存遊戲物件的各種屬性，例如生命值 (int)、速度 (float)、是否隱形 (bool)。屬性的型別各不相同。

public class GameObject_Modern
{
    private Dictionary<string, object> _properties = new Dictionary<string, object>();

    // SetProperty 仍然會導致 Boxing，但在某些動態情境下這是可接受的折衷
    public void SetProperty<T>(string key, T value)
    {
        _properties[key] = value;
    }

    // **解決方案: 提供一個泛型 Get 方法**
    public T GetProperty<T>(string key)
    {
        if (_properties.TryGetValue(key, out object value))
        {
            // **優點: 在一個地方集中處理型別安全**
            if (value is T typedValue)
            {
                // 這裡的拆箱是受控且經過檢查的
                return typedValue;
            }
        }
        // 返回該型別的預設值 (例如 int 是 0, bool 是 false, class 是 null)
        return default(T);
    }
}

// 使用
var player = new GameObject_Modern();
player.SetProperty("Health", 100);
player.SetProperty("Speed", 5.5f);
player.SetProperty("IsInvisible", false);

// **優點: 取得資料時是型別安全的，且無需手動轉型**
int health = player.GetProperty<int>("Health");         // 無需轉型
float speed = player.GetProperty<float>("Speed");       // 無需轉型
bool isInvisible = player.GetProperty<bool>("IsInvisible"); // 無需轉型

// **優點: 取得不存在或型別錯誤的資料時，不會崩潰**
string name = player.GetProperty<string>("Name"); // 安全地返回 null
float health_wrong = player.GetProperty<float>("Health"); // 安全地返回 0.0f

Console.WriteLine($"Health: {health}, Speed: {speed}, IsInvisible: {isInvisible}, Name: {name ?? "N/A"}");

🌺 結語

那塊碎石，終究沒有馬上離開河岸。
但從那天起，它開始注意溪水的節奏，聽見水聲裡的包容與轉圜，開始學著鬆動自己的邊界。

或許有一天，它真的會被時間與流動磨圓，隨波而行。又或許，它會在原地，長出一種新的彈性，懂得在不同情境中調整姿態。

這不也正如我們的程式嗎？

我們學會讓整數化為小數，以精準因應金融需求；
讓物件披上更抽象的外衣，以納入更多未來的可能；
也學會在必要時將泛型與類型重新切換，在穩定與效能之間取得平衡。

程式語言的轉型，不只是語法的轉換，更是認知的柔軟。是一種在有限邏輯下，為資料找尋最佳容身之處的藝術。
而身為開發者的我們，也像那塊碎石，在一行行程式中，慢慢學會了如何轉、何時轉、為誰轉。

最終，我們不再只是一塊靜止的石頭，而是成為了那能隨時變形，因應需求、因地制宜的「水」 —— 流過錯誤，繞過限制，淌向更遼闊的可能。