私は、オブジェクト指向プログラミングの美徳を称賛するエッセイを書き、それらを実証するための付随するゲームを作成する任務を負っています。
私の最初のアイデアは、OOP パラダイムに従わないプログラミング言語で書かれた (または OOP 言語で書かれているが OOP の方法ではない) シンプルなゲームのチュートリアルを見つけ、C# または Java を使用して OOP の方法でそれを再作成することです。 （まだ決めていません）。これにより、2 つを具体的に比較することができます。
ゲームは複雑なものである必要はありません。テトリス、ポンなど。私がこれまでに抱えていた問題は、適切なチュートリアルを見つけることです。何か提案はありますか?
OOPにないゲームのソースコードを見つけたとしましょう。エッセイで指摘できるOOPの長所がいくつかあります。
組織。 ゲームには多くのタスクがあるため、1つのクラスに責任を割り当てることをお勧めします。これは、スコアを保持する1つのクラス、ファイルアクセス（ゲームの状態の読み取りと書き込みなど）を行う1つのクラス、キャラクターを表すクラスなどを作成することを意味します。それ以外の場合は、数千行のコードを含む1つの巨大なテキストファイルが作成されます。必要なものを見つけて修正することは言うまでもなく、それを見ることさえも悪夢です。
カプセル化。 これは、より良い編成のためにプロパティと機能をグループ化しています。以前は、各プロパティを格納するために異なる配列を使用していました。たとえば、航空機名用の1つの配列、火力用の1つの配列、最高速度用の別の配列などです。これらすべての配列で同じインデックスを確認する必要があるため、これは残念です。実際に正しい航空機を説明します。Aircraftオブジェクトを作成し、それらのプロパティ名を付けることをお勧めします。これで、航空機を保持する1つのアレイができます。あまりにも多くのアレイを追跡する必要はありません。
再利用性。 より多くのゲーム（および他のアプリ）を作成すると、クラスを再利用する必要が生じます。たとえば、ソリティアゲームでは、将来作成するカードゲームと同じカードクラスを使用します。
ポリモーフィズム/継承。 ある種のグリッドにヒーローと悪役の両方の各キャラクターを表示したいとします。ヒーローと悪役の両方がキャラクターを継承するようにします。文字には共通のプロパティがあり、[n abstract] Display（）関数もあります。次に、CharacterとVillain（描画のためにクラス固有のデータにアクセスする）用のカスタムDisplay（）関数を記述します。次に、キャラクターオブジェクトの配列を作成し、各スロットに悪役またはヒーローのいずれかを格納できます。ゲームがそのリストを調べて表示するとき、各item.Display（）呼び出しは、キャラクターの実際のタイプに基づいて正しいDisplay（）関数を自動的に選択します。OOPなしでこれを実行しようとすると、長いif-else（およびおそらくネストされた）ステートメントとすべての描画ルーチンが1か所に配置されてしまいます。
これは、一般的なプログラミングの経験から得た私の頭のタイプであり、ゲームプログラミングに確実に適用できます。おそらく言及されているよりも多くのOOPの側面があるので、調査することをお勧めします。あなたのエッセイのためのすべてのベスト！
このサイトから BASIC ゲームを試してください: