利用RTTI可根據一個匿名的基礎類句柄調查出類型信息。但正是由於這個原因，新手們極易誤用它，因為有些時候多形性方法便足夠了。對那些以前習慣程序化編程的人來說，極易將他們的程序組織成一系列switch語句。他們可能用RTTI做到這一點，從而在代碼開發和維護中損失多形性技術的重要價值。Java的要求是讓我們盡可能地采用多形性，只有在極特別的情況下才使用RTTI。
但為了利用多形性，要求我們擁有對基礎類定義的控制權，因為有些時候在程序范圍之內，可能發現基礎類並未包括我們想要的方法。若基礎類來自一個庫，或者由別的什麼東西控制著，RTTI便是一種很好的解決方案：可繼承一個新類型，然後添加自己的額外方法。在代碼的其他地方，可以偵測自己的特定類型，並調用那個特殊的方法。這樣做不會破壞多形性以及程序的擴展能力，因為新類型的添加不要求查找程序中的switch語句。但在需要新特性的主體中添加新代碼時，就必須用RTTI偵測自己特定的類型。
從某個特定類的利益的角度出發，在基礎類裡加入一個特性後，可能意味著從那個基礎類衍生的其他所有類都必須獲得一些無意義的“雞肋”。這使得接口變得含義模糊。若有人從那個基礎類繼承，且必須覆蓋抽象方法，這一現象便會使他們陷入困擾。比如現在用一個類結構來表示樂器（Instrument）。假定我們想清潔管弦樂隊中所有適當樂器的通氣音栓（Spit Valve），此時的一個辦法是在基礎類Instrument中置入一個ClearSpitValve()方法。但這樣做會造成一個誤區，因為它暗示著打擊樂器和電子樂器中也有音栓。針對這種情況，RTTI提供了一個更合理的解決方案，可將方法置入特定的類中（此時是Wind，即“通氣口”）——這樣做是可行的。但事實上一種更合理的方案是將prepareInstrument()置入基礎類中。初學者剛開始時往往看不到這一點，一般會認定自己必須使用RTTI。
最後，RTTI有時能解決效率問題。若代碼大量運用了多形性，但其中的一個對象在執行效率上很有問題，便可用RTTI找出那個類型，然後寫一段適當的代碼，改進其效率。
