2

私は現在、おそらく75％完了しているチェスゲームを構築しています。これは計画がゼロの衝動的なものであり、したがって非常に厄介です。

3つの多次元配列があります。1つは列挙型Colour、もう1つは列挙型ChessPiece、最後は座標を含みます。

これを片付けたいのですが、考えられることが2つあります。

1）オブジェクト指向プログラミング。Colour、Coordinates、Pieceの各プロパティを持つクラスを作成し、ゲームの開始時に各ピースをインスタンス化して、各インスタンスを参照することができます。

2）はるかに簡単な方法は、クラスのプロパティと同様に、ボタンコントロールにプロパティを追加できる場合です。つまり button1.Piece = Pawn、button1は実際のボタンを指します。

これを行う方法はありますか？ありがとう。

4

2 に答える 2

6

それは次のように単純かもしれません：

public class ChessButton : Button
{
    public ChessPiece { get; set; }
}

明らかに、あなたはあなたが望むことをするためにChessButton（恐ろしい名前）を拡張する必要があるでしょう。

于 2013-01-25T11:41:30.590 に答える
1

さて、あなたが最初のアプローチ（ooパラダイム内で物事を行うため）をとるなら、私はあなたがかなりきちんとしたモデルを思い付くことができると想像することができました。基本クラスのPieceを想像することができます。これは、Prawn、Rook、Bishopなどのクラスに継承され、ピースを移動するための「ルール」を実装する可能性があります。同様に、クラスTileとBoardと呼ばれる別のクラス（タイルの2次元配列を含む）を想像することができます。などなど。

したがって、これは最終的には非常にきれいできれいであると考えることができます。これらすべてのクラスについて考え、それらが何をするのか、そしてそれらが他のクラスとどのように相互作用するのかを理解する必要があります。そのため、設計の要素があり、これは潜在的な欠点です。具体的な利益なしに事前に考えなければならないということです。アプリが存在するためのインフラストラクチャをほぼ構築していることになります。彼らがうまくいけば、何が起こっているのかを非常に簡単に理解できるだろう誰か。だからその維持可能。そして、ooアプローチには大きなメリットがあります。

2番目のアプローチ（UIクラスの拡張）。さて、あなたが言うように、それははるかに簡単に思えます。そして、おそらくアプリが十分に単純であれば、それが進むべき道です。

しかし、あなたはまた、これまでアドホックベースで物事を行ってきたと言っており、そのすべてが非常に厄介です。そして、あなたが遭遇したものは、UI開発の典型です-構造化されていないアプローチで物事を構築すると、物事は厄介になります。何年にもわたって、人々は保守性を向上させるためにフロントエンドに構造を追加しようとすることに多くの時間とお金を投資してきました。この質問にc＃のタグを付けると、MVC、MVVM、MVPなどのMicrosoftのことを聞いたことがあるかもしれません。必ずしもこれらのアプローチを詳細に確認する必要はありません。UIコードを区画化してすべてを管理しやすくするために、それらが存在する理由を理解する必要があります。

ここでの動機の1つはコードをクリーンアップすることでもあるとおっしゃっていますので、デフォルトで「はるかに簡単な」パスを使用するのではなく、構造化されたアプローチを検討することをお勧めします。

あなたがそれについて考えて、ボタンを拡張することに決めたなら、結構です。構造化アプローチよりもそれを選択する理由は、構造化アプローチには非常に多くの労力が必要になるためです。しかし、少なくともあなたはそれについて考えました。将来的には、はるかに複雑なUI要件に直面することになり、この種の事前の考えが利益を生むでしょう。

于 2013-01-25T11:57:23.177 に答える