在代碼複用和組織數據方面，面向對象可能是大家第一反應。面向對象三大特性繼承，封裝，多態，在一定程度上能解決不少代碼複用，數據複用的問題。不過面向對象不是萬能的，它也有極大的缺陷：
1. 數據組織耦合性及強。
一旦父類中增加或刪除某個字段，可能要影響到所有子類，影響到所有子類相關的邏輯。這顯得非常不靈活，在一套複雜的繼承體系中，往父類中改變字段會變得越來越麻煩，比方說ABC是D的子類，某天發現需要增加一個AB都有的數據，但是C沒有，那麼這個數據肯定不好放到父類中，只能將AB抽象出來一個父類E，E繼承於D，AB共有的字段加到E中，一旦繼承結構發生了變化，可能接口也要改變，比方說之前有個接口傳入參數類型是E，當AB不在需要共用的那個字段，那麼需要調整繼承關係，讓AB重新繼承D，那麼這個接口的傳入參數類型需要改成D，其中的邏輯代碼很可能也要發生調整。更可怕的是遊戲邏輯變化非常複雜，非常頻繁，可能今天加了個字段，明天又刪掉了，假如每次都要去調整繼承結構，這簡直就是噩夢。繼承結構面對頻繁的數據結構調整感覺很無力。還有個嚴重的問題，繼承結構無法運行時增加刪除字段，比如玩家Player平常是走路，使用坐騎後就騎馬。問題是坐騎的相關信息就需要一直掛在Player對象上面。這就顯得很不靈活，我不騎馬的時候內存中爲啥要有馬的數據？
2. 接口邏輯難以複用，難以熱插拔。
面向對象處理相同行爲所使用的方法是繼承相同的父類或者接口。問題是接口並沒有實現代碼，而是需要其子類自己去寫相關實現。很顯然相同的功能，每個子類都可能寫一份相似的代碼。這導致接口的實現代碼無法複用。還有個問題，一個類實現了一個接口，那麼這個接口就永遠粘在了這個類身上，你想甩掉她都不行，還是以騎馬爲例，玩家Player可以進行騎行，那麼可能繼承一個騎行的接口，問題是，當我這個Player從坐騎上下來時，玩家Player身上還是有騎行的接口，根本沒法動態刪掉這個接口！可能例子舉得不是很對，但是道理表述的應該很清楚了。
3. 使用面向對象可能導致災難性後果
遊戲開發中有新人有老人，有技術好的，有技術差的。人都是喜歡偷懶的，當你發現調整繼承關係麻煩的時候，有可能AB中增加一個字段爲了省事直接就放到父類D中去了。導致C莫名奇妙的多了一個無用的字段