2

私は主にエレクトロニクスのバックグラウンドを持つ学生で、プログラミングを始めています。やり込めば入るほど、自分がいかに下手かを思い知らされます。私はオブジェクト指向の設計を上達させようとしています。私が読んでいることの 1 つは、ゲッターとセッターの使用です。

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 http://Typicalprogrammer.com/?p=23

彼らがここで主張していることは理解できますが、いくつかの単純な問題を回避することはまだできません。そして、これは私の質問につながります（最後に）。学習課題として、AS3 で簡単なタワー ディフェンス ゲームをセットアップしています。敵にウェイ ポイントをたどってもらいたいので、ウェイ ポイントの配列を作成し、それをマップ オブジェクトのプロパティにしました。そして、通過点は​​、x および y プロパティ (より構造体に似たもの) を持つオブジェクトになることでした。今では、これがまさに記事が思いとどまらせている一種の悪い習慣であることがわかりますが、これを行うためのより良い方法を思いつかないようです. もう少し経験のある皆さんからの助けをいただければ幸いです。

4

4 に答える 4

3

まず一般化します。あなたは現在、敵にウェイポイントをたどってもらいたいと思っていますが、あなたが持っているのは、何かがどこに移動するかを決定するマップの特定のインスタンスであるように私には思えます。

敵を「GameEntity」（おそらくMoveableGameEntity）のインスタンスと呼びましょう。

あなたがしなければならないことは、関連するGameEntitiesを管理するようにマップに指示することです。そうすれば、マップはこれらのオブジェクトのリストを保持し、必要に応じてそれらを移動できます。

コードフラグメント。

interface  MoveableGameEntity
{
    void positionNotify(Position new_postition);
};

public class Barbarian implements MoveableGameEntity
{
    void positionNotify(Position new_postition)
    {
         // do something
    }
};

// during initialisation.
map.Add(new Enemy("Barbarian 1"));
map.Add(new Enemy("Barbarian 2"));

//during map processing
Position new_position = new Position();
for (MoveableGameEntityList moveable : moveable_game_entity_items)
{
   new_position = get_new_posistion(moveable);
   item.moveTo(new_position);
   moveable.positionNotify( new_position );
}

マップには、新しい姿勢を決定するメソッドget_new_position（MoveableGameEntity ge）が必要であり、敵は、positionNotifyメソッドを介してのみ新しい姿勢を通知されます。

MoveableGameEntityListは、ゲームエンティティとその位置を結び付けるオブジェクトです。このように、ゲームエンティティには位置情報が含まれず、これは別のオブジェクトによって管理されます。

于 2010-02-28T12:44:49.473 に答える
2

わかりました、重い仮定が続きます: 効率について考えすぎていると思います。OO コーディングは効率に関するものではありません。エレガントなデザインについてです。外部要因による副作用を最小限に抑え、内部状態を保護することです。これが、コンパイラが「最適化」する理由です。保守性とコーディングの難しさを第一に考えるべきです。作成する行数は、OO 以外のコードよりも多くなる可能性があります。それはポイントではありません。

あなたの「物」を、互いに通信する有形のアイテムと考えてみてください。この通信はプロトコルです (メソッド署名を含みます)。お互いに「話す」言語。シンプルで明確なものにしてください。オブジェクトには、提案や要求を伝達する能力 (カプセル化) を超えて別のオブジェクトを操作する能力があると想定しないでください。

ゲッターとセッターを目的もなくすべてに追加しないでください。ポイント全体を見逃してしまい、別のスタイルでコーディングしている可能性があります。内部状態を保護します。すべてのゲッターとセッターは、普遍的に非効率的な実装になることを意味します。セッターとゲッターはゲートキーパーです。これ以上何もない。意味がない場合は削除してください。使用する場所で使用してください。他の何かがあなたの内部状態を台無しにすることを決して許してはなりません。混乱を招きます。

ゲームを作成するとき、これらのプラクティスは失敗しますが、放棄することはできません。クリティカル ループとチョーク ポイントを最適化します。元のコードを参照用および最適化されたコードの鏡像モデルとして保持します。必要なショートカットだけを使用してください。最適化は常に最後に行う必要があります...明らかに非効率的でありながら思慮深い設計に直面した場合でも。

私が一緒に働いた多くの元Javaコーダーは、不必要に属性にセッターとゲッターを置きました（すべての属性）。これは単に彼らが慣れているものです。10 例中 9 例で利益はありませんでしたが、彼らはこのパターンに固執していました。影響は常にごくわずかでした (1 分あたり 50,000 ユーザー... もちろん、Java は使用していませんが、それでもなお)。高レベルの設計では、ゲッターとセッターの全体的な影響は最小限です。ビデオ CODEC や OpenGL のように、下位レベルでは巨大です。

何も考えずに採用することも、適用性を念頭に置いて実装することもできます。多くの教授が、あなたがそれらを省略したために「間違っている」と言っているのを目にするでしょう。コースワークへの期待を念頭に置いてください。:)

于 2010-02-28T06:52:18.517 に答える
1

少し関係はありませんが、オブジェクト指向デザインに興味がある場合は、理解しやすく理解しやすい2冊の優れた本を用意しています。

ヘッドファースト：OOAD

ヘッドファースト：デザインパターン

于 2010-02-28T12:49:31.820 に答える
1

私は、これを悪い習慣と良い習慣とではなく、パラダイムの変化と見なしたいと考えています。残念ながら、スイッチを入れるだけという単純なものではありません。これは、物事の見方の違いを経験するにつれて、徐々に起こることです。

私があなたにできる最善のアドバイスは、コーディングを始めることです。多くの。

于 2010-02-28T05:48:37.357 に答える