2

たとえば、ゲームのAPIを設計する場合。データ構造をプライベートに保つ方が良いでしょうか、それとも、優れた設計と見なされるAPIを使用している開発者/開発者に構造を返すのでしょうか?だからここに例があります。

チェス盤のゲームAPIがあると仮定します。次の2つの例のどちらが「より良い」と見なされますか?この質問の目的のために、私はチェス盤のサイズが変化する可能性があり、開発者によって制御されると想定していることに注意してください。

public void createboard(ChessBoard board);
public void move(Player playerNumber, Move move);

また

public void createboard(int x, int y);
public void move(Player playerNumber, int from[], int to[]);

これ以上の答えはないかもしれませんが、それは設計上の決定の問題であることを理解しています。私は他の人がどう思うか、または誰かが持っている有用なヒントがあるかどうかを見ようとしています。

基本的に、ゲームには実際のボードの2D配列を含むChessBoardというオブジェクトが含まれていると想定しています。

最初の例では、開発者がオブジェクトを作成して渡す必要があり、開発者は基礎となるデータ構造が何であるかを実際に知っている必要があります。

ただし、2つ目は、開発者が数字のみを渡す必要があります。これは、これを使用する開発者に独自のデータ構造を維持するように要求します。

より良いデザインを検討するアプローチはどれですか?任意のヒント?

4

2 に答える 2

1

APIを公開する場合、内部実装が多いほど、非表示になります。そうしないと、APIの以前のリビジョンを使用している開発者とのバイナリ互換性を壊したくないため、今後の拡張/変更に関して自分自身を制限する可能性があります。(「実際の」ケースでは、APIに関してクライアントと顧客の間で、顧客からの明示的な許可なしにAPIを破ることはできないという合意書が作成される場合があります)。

APIを介した構成を許可することを目指し、特定の実装に内部的にロックしないようにする必要があります。思ったより難しいし、使われている言語も要因です。

于 2012-10-25T13:44:08.847 に答える
1

私の意見では、「エンジン」をどれだけ用途が広いかが重要になります。

チェスの表示だけが必要な場合は、APIユーザーから実際のボードを非表示にします。APIユーザーがエンジンをたとえばArchonクローンに拡張できるようにする場合は、ボードを好みに合わせて拡張できるようにする必要があります。

于 2012-10-25T13:55:53.800 に答える