5

私のアプリケーションには、インスタンスInstrumentFactoryを作成する唯一の場所があります。各インストゥルメント インスタンスには、 andや uniqueInstrumentなどのいくつかのフィールドが含まれています。Ticker=MSFTGateId=1Id =1

Instrumentそして今、インスタンスはほとんど必要ないことに気付きました。ケースの 90% で、必要なだけですId。たとえば、今私はそのような方法を持っています:

public InstrumentInfo GetInstrumentInfo(Instrument instrument)
{
    return instrumentInfos[instrument.Id];
}

必要以上の情報をパラメーターに渡してはならないことはわかっています。したがって、このコードはおそらく次のようにリファクタリングする必要があります。

public InstrumentInfo GetInstrumentInfo(int instrumentId)
{
    return instrumentInfos[instrumentId];
}

コードの 90% をリファクタリングして、instrumentId代わりに使用できるようになりInstrumentました。

私はそれをすべきですか？すべての場所Instrumentを に変更instrumentIdすると、難しい要件になります (各インストゥルメントには、一意の ID が 1 つだけ必要です)。しかし、私にはどのようなメリットがありますか？「ハード要件」の見返りに、そのためにいくつかの利点が必要です...（速度、読みやすさ？）しかし、私はそれらを見ていません。

4

5 に答える 5

4

オブジェクトの代わりにどこでもIDを使用することは間違ったアプローチであり、OOPの精神に反します。

オブジェクト自体を使用することには、2つの大きな利点があります。

  1. タイプセーフです。Person誤って最初のバージョンのようなものを渡すことはできませんが、誤っperson.Idて2番目のバージョンに渡すことはできます。
  2. コードを簡単に変更できます。将来、IDが必要であると判断した場合long、または一意を識別する他の方法が必要なInstrument場合は、呼び出し元のコードを変更する必要はありません。

そして、おそらく辞書も変更する必要があります。現在のようDictionary<Instrument, InstrumentInfo>にではなくDictionary<int, InstrumentInfo>、のようなものにする必要があります。このようにして、そこにも両方の利点があります。それを機能させるには、で等式を実装する必要がありますInstrument。これは、を適切にオーバーライドEquals()しGetHashCode()、理想的にはも実装することを意味しますIEquatable<Instrument>。

于 2012-08-12T17:45:18.993 に答える
1

整数のようなプリミティブ値よりも、オブジェクトの観点から作業する方が常に優れています。明日、要件が変更され、IDだけでなくそれ以上のものが必要になった場合は、Instrumentすべてのコードを変更する代わりに、それらをオブジェクトに追加するのは簡単です。

于 2012-08-12T17:44:58.680 に答える
1

最初に自問する必要があるのは次のことです。

「ID == 53 の楽器が 2 つある場合、それらは間違いなく同じ楽器であることを意味しますか? それとも、それらが異なる可能性がある意味のあるケースはありますか?」

答えが「両方とも同じである」と仮定すると、他のプロパティが異なる場合、それはバグであるか、そのようなオブジェクトが次々に取得されたためであり、それはすぐに解決されます (処理のスレッドが古い楽器を使用している場合) 、使用をやめる)" の場合:

まず、内部的には、使いやすいと思われるものを使用してください。anがメソッドに渡されるintことを主張することである程度の型安全性が得られますが、これは常に行われていることに気付くでしょう。これは、すべての構築がファクトリ メソッド経由でアクセスされるorコンストラクターから行われ、コードのユーザーがシステム内のどの ID とも一致しない偽の IDを作成する方法がないInstrument場合に特に当てはまります。InstrumentinternalprivateInstrument

等式を次のように定義します。

public class Instrument : IEquatable<Instrument>
{
  /* all the useful stuff you already have */
  public bool Equals(Instrument other)
  {
    return other != null && Id == other.Id;
  }
  public override bool Equals(object other)
  {
    return Equals(other as Instrument);
  }
  public override int GetHashCode()
  {
    return Id;
  }
}

さて、特に上記がほとんどの場合インライン化される可能性が高いと考えると、ID を使用するかオブジェクトを使用するかに関して、同等性に関して実装上の違いはほとんどなく、したがってそれらをかぎ。

これで、次のいずれかの方法ですべてのパブリック メソッドを定義できます。

public InstrumentInfo GetInstrumentInfo(Instrument instrument)
{
    return instrumentInfos[instrument];
}

または：

public InstrumentInfo GetInstrumentInfo(Instrument instrument)
{
    return instrumentInfos[instrument.Id];
}

または：

public InstrumentInfo GetInstrumentInfo(Instrument instrument)
{
    return GetInstrumentInfo(instrument.Id);
}
private InstrumentInfo GetInstrumentInfo(int instrumentID)
{
    return instrumentInfos[instrumentID]
}

どちらを選択しても、パフォーマンスへの影響は同じです。ユーザーに提示されるコードはタイプ セーフであり、偽の値を渡さないことが保証されます。選択される実装は、他の理由でより便利であると思われる単純なものにすることができます。

インストゥルメント自体を内部でキーとして使用するのにこれ以上コストがかからないため、型安全性と偽の値の受け渡しを困難にするために、(上記の 3 つのオプションの最初の) それを行うことをお勧めします。その後、内部コードにも適用されます。一方、呼び出しのセットがとにかく id を使用し続けることがわかった場合 (たとえば、ID だけが何かを意味するデータベース層と通信している場合)、それらの場所だけをすばやく簡単に変更できます。ユーザーから隠されています。

また、ユーザーが必要に応じて、オブジェクトをキーとして使用し、迅速な等値比較を実行できるようにします。

于 2012-08-12T17:54:58.113 に答える
1 
GetInstrumentInfo(int instrumentId);

これはおそらく、クライアント コードに次のものが必要であることを意味します。

GetInstrumentInfo(instrument.Id);

メソッドのユーザーにそのような細かいことを心配させないでください。オブジェクト全体を渡すだけで、メソッドが機能します。

大きなパフォーマンス上の欠点は見られません。Int を渡すか、実際のオブジェクトへの参照を渡すか。

GetInstrumentInfo をもう少し開発したいとします。Int だけでなく、オブジェクト全体にアクセスする方が簡単です。

于 2012-08-12T17:51:27.100 に答える
-1

各関数をオーバーロードできます。1 つはインストゥルメントを受け取り、もう 1 つは ID を受け取ります。

public InstrumentInfo GetInstrumentInfo(Instrument instrument)
{
    // call GetInstrumentInfo passing the id of the object
    return GetInstrumentInfo[instrument.Id];
}

public InstrumentInfo GetInstrumentInfo(int instrumentId)
{
    return instrumentInfos[instrumentId];
}

これにより、十分な柔軟性が得られるため、GetInstrumentInfoid を渡すように変更するために呼び出す場所を通過している間、現在のコードは引き続き機能します。

あなたが「すべき」かどうかについては、純粋にあなた次第です。コードを変更するのにかかる時間と、コードを変更することの利点を比較検討する必要があります。

于 2012-08-12T17:48:33.360 に答える