我曾經和尊重過的人曾經向我表示，應用程序代碼中不應該有任何需要使用反射的情況，而且應該只在框架中使用。他是從J2EE背景來講的，我在該平臺的專業經驗通常會證明這一點;儘管我已經使用Java編寫了一次或兩次反射式應用程序代碼。反思：僅針對框架？
我對Ruby on Rails的體驗完全不同，因爲Ruby幾乎鼓勵您編寫動態代碼。如果沒有反射和元編程，許多Rails給你的東西都是不可能的，許多相同的技術對你的應用程序代碼同樣適用和有用。
有一個古老的笑話，用靜態類型語言編寫的任何足夠複雜的系統都包含Lisp的不完整，低劣的實現。
由於隨着項目的發展您的需求會變得越來越複雜，您最終會發現靜態類型對象系統中常見的習慣用法最終會碰壁。有時候進行反思是最好的解決方案。
我很喜歡Ruby等動態類型語言和像C＃這樣的靜態類型語言，但Ruby中的隱式反射常常使得代碼更簡單易讀。 （根據所需的元編程魔法，有時難寫）。
在C＃中，我發現如果沒有反射，無法解決的問題，因爲我沒有運行前的信息。一個例子：當試圖處理一些生成代理到另一個進程中運行的Silverlight對象的第三方代碼時，我不得不使用反射來調用特定的強類型「通用」版本的方法，因爲編組需要調用者假定另一個進程中的對象類型是爲了從中提取我們需要的數據，並且C＃不允許在運行時指定泛型方法調用的「類型」（除了使用反射技術）。我猜你可能會認爲我們的工具是一種框架，但我可以很容易想象一個普通應用程序面臨類似問題的情況。
我不同意，反射在應用程序代碼中非常有用，我發現自己經常使用它。最近，我不得不使用反射來從程序集的路徑加載程序集（以便調查其公共類型）。當沒有其他辦法
對這個問題的若干意見在這裏表達...
使用反射！這是一個表現的問題！如果您之前查看過.NET性能問題，它可能並不會讓您感到驚訝，正常反射的速度有多慢：通過重複訪問int屬性的簡單測試證明，使用反射比直接反射速度低1000倍進入該物業（比較平均80％的測量時間的平均值）。
看到這個：.NET reflection - performance
MSDN有一個相當不錯的一篇關於When Should You Use Reflection?
如果您的問題最好通過使用反射解決，你應該使用它。
（請注意，「最佳」是每個人所經歷中學:)
框架與應用程序的定義的定義是不是所有的黑白色&要麼。有時候你的應用需要一些框架來完成它的工作。
反射使DRY變得更容易。無需反射就可以編寫DRY代碼，但通常要冗長得多。
如果某種信息以某種方式編碼在我的程序中，爲什麼不會如果這是最簡單的方法，我使用反射來實現它？
這聽起來像他在談論Java專門。在這種情況下，他只是引用了一個特例：在Java中，反射非常不可靠，它幾乎從來都不是最簡單的方法。 :-)在Ruby等其他語言中，正如你所看到的那樣，它通常是。
反射在框架中絕對大量使用，但正確使用可以幫助簡化應用程序中的代碼。
我之前見過的一個例子是使用大型接口（20+方法）的JDK代理來封裝（即委託給）特定實現。只有幾個方法被InvocationHandler覆蓋，剩下的方法通過反射來調用。
反射可能很有用，但執行常規方法調用會更慢。看到這個reflection comparison。
Java中的反射通常不是必需的。這可能是解決某個問題的最快方法，但我寧願找出導致您認爲在應用程序代碼中有必要的基本問題。我相信這一點，因爲它經常將編譯時的錯誤推向運行時間，對於足夠大的軟件來說，測試是不平凡的，這總是一件壞事。
我認爲在應用程序代碼中不應該有任何需要使用反射的觀察，並且應該只在框架中使用它，這或多或少都是事實。
關於如何耦合某段代碼的範圍，通過反射加入的代碼在它們到來時如同鬆散耦合。
因此，通過反射來完成它的工作的代碼可以非常高興地履行它在生活中的作用，因爲它知道正在使用它的代碼並不是一件事情。
這將是格林斯潘的第10條規則「任何足夠複雜的C或Fortran程序包含一個臨時的，非正式指定的，錯誤纏身，緩慢實現一半的Common Lisp」 – JMM 2009-05-01 02:52:20