1.1 元編程的需求背景

我們在編寫程序時經常會遇到一個問題—重復，而工程師最不能忍受的就是重復。重復意味著低效，也意味著低級。我們造的每一個“輪子”在某種意義上都是為了解決重復的問題。業內也有一句名言：“不要重復你自己（Don't repeat yourself）。”

然而在實際的業務場景中，我們經常會見到大量重復或者相似的模板代碼，這些代碼很多時候難以使用編程語言的基本特性進行抽象，因此我們不得不忍受它們的存在。

Java的Getter方法和Setter方法就是很典型的例子，如代碼清單1-1所示。

幸運的是，Kotlin把屬性作為正式的特性提供給開發者，使得開發者終于不用忍受充斥著Getter和Setter的模板代碼了，如代碼清單1-2所示。

不過，不是所有模板代碼問題都能通過添加語法特性解決。

業務代碼中最常見的網絡請求就是高度模板化的代碼。不同的業務接口雖然各不相同，但網絡請求本身的代碼極為相似。以OkHttp為例，如代碼清單1-3所示。

我們定義了兩個函數getUser和getRepository，分別用于請求GitHub的API以獲取用戶和倉庫的相關信息。這兩個函數除了參數、返回值和請求的URL不同以外，剩下的代碼完全相同，而這部分相同的代碼才是這兩個函數的主體內容。如果調用者希望接口同時提供異步回調和協程的版本，情況只會更糟糕。異步回調和協程版本的接口函數如代碼清單1-4所示。

在實際的業務場景中，請求幾十甚至上百個接口是非常常見的事情。可以想象，重復的接口代碼實現將會給項目帶來巨大的維護成本。

解決此類問題最常用的手段就是元編程。Kotlin提供了非常豐富的元編程手段，包括運行時反射（Kotlin JVM）、編譯時符號處理等。

Retrofit就是一個充分運用運行時反射能力來簡化HTTP接口代碼的框架。它可以以非常優雅的方式解決代碼清單1-3和代碼清單1-4中存在的問題，如代碼清單1-5所示。

3.3節將對Retrofit的工作機制進行剖析。