若干釣り気味です、すいません！！！！！！というかまさかり期待してます、ください。
題の通りです。オブジェクト指向パラダイムはゲームプログラミングと相性が悪いです。
どうもプロのゲームプログラマには常識っぽいんですが、ホビーゲームプログラマにはあまり浸透してないみたいです。（調べてようやく認識しました……）
##ある日曜プログラマの憂鬱
ある日突然モグラたたきが作りたくなりました。なったんです！！
さて、モグラ叩きに登場するオブジェクトを考えます。
モグラが当然いりますね。
というわけでこんな感じに設計しました。
詳細な実装をつめていって、とうとうプロトタイプが完成しました！！
やった！！…と言いたいところなんですが、なんだか物足りないのです。
そこでかんがえました、叩いたらダメなウサギを作ろうと。
出たり引っ込んだりするのは同じなので、モグラを継承することにしました（説明のためわざとです、突っ込みたい気持ちは抑えて！！）
そのあとひたすらコーディングして完成！！しましたが、完成したらしたで、また新たなゲーム要素を思いつきました。おばけです、穴からふわーりと飛んでいく。面白そうですね、面白そうです。
さて、これはウサギともモグラとも動きが違います。よって動きは共有できないのです。そこではたと気がつきました（やっとです）、共通コードをベースクラスにすればよいと！！
早速この考えを元に設計し直します……
……あれ？これだと出たり引っ込んだりするコードが共有できてませんね？
ならば、と再びペンを走らせます……
……今度はおばけに不要なコードがベースクラスにくっついちゃいました。はたしでどっちがいいのやら！？
##銀の弾丸は無い
データベースとオブジェクト指向の間には溝があります。インピーダンスミスマッチと呼ばれていますが、ゲームを構築する際にも、インピーダンスミスマッチが生じています。
ゲーム世界をプログラムコードに落とす上で、継承という仕組みは貧弱すぎるのです。
これはかなり早い段階で認識されていたようで、いくつか解決策が提示されています。
##Entity Component System
継承がだめならコンポジションです。オブジェクトの粒度を非常に小さくして、それを集めれば良いのです。UnityのMonoBehaviorはまさにこの構造になります。
欠点：
依存関係を粗にしようとすると、オブジェクト間通信のコストが高くつきます。
また依然としてオブジェクト指向なため、ハードウェアと相性が悪いです。
##Data Oriented Programming
オブジェクト指向では、データを外から守るオブジェクトという単位でプログラムを構成します。
ですが、DOPではデータを中心に考えます。プログラムを、データを変形するライン工場と見立てるのです。
ECS実装のもう一つのアプローチでもあります。
このプログラミングアプローチは、現代的ハードウェアと相性が良いです。（並列化しやすい、キャッシュに載る）
欠点：
発想の転換が求められます。
##Functional Reactive Programming
DOPをもうちょっと眺めてください。
はい、工場、という言葉、Haskellの入門書等で見ますよね。
データを加工する工場、とはすなわち、関数に他なりません。
Functionalというと副作用がどうのこうのが気になりますよね。
ゲームというのは副作用の塊です。相性悪いなんてものじゃなさそうですが……
大丈夫です。
コンピュータは離散で時間を扱います。0msの世界を16ms後の世界に変換する関数、それこそがゲームロジックです。これを連続的に行えば、ゲームは表現できます。
これを関数型の世界で上手く表現する手法、それがFRPになります。
Elmという言語がFRPにフォーカスした言語らしいので、誰かレポートしてください！
欠点：
Haskell……うっ、頭が……
##結論
趣味レベルの規模だとどうでもいい気がします。
コード把握してる限りは何使っても同じですし……
とこの記事の意義をぶちこわして終了です。またどこかで！