当我需要某些物品时，我应该只使用它的“ int id”吗？

Question

我的应用程序具有InstrumentFactory创建Instrument实例的唯一位置。 每个乐器实例都包含几个字段，例如Ticker=MSFT和GateId=1以及唯一的Id =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会很困难（每个Instrument都应该有一个唯一的ID）。 但是我会得到什么好处？ 作为“硬性要求”的回报，我希望为此获得一些好处……（速度，可读性？）但是我看不到它们。

Answer 1

在各处使用id而不是对象是错误的方法，这违背了OOP的精神。

使用对象本身有两个很大的优点：

1. 这是类型安全的。 您不能无意间将诸如Person之类的东西传递给第一个版本，但是您可以无意间将person.Id传递给第二个版本。
2. 它使您的代码易于修改。 如果将来您决定需要long ID或其他方法来标识唯一的Instrument ，则无需更改调用代码。

而且您可能还应该更改字典，它应该像现在一样，类似于Dictionary<Instrument, InstrumentInfo> ，而不是Dictionary<int, InstrumentInfo> 。 这样，您就可以同时获得这两个优点。 要使其正常工作，您需要在Instrument实现相等性，这意味着适当地重写Equals()和GetHashCode()并在理想情况下还实现IEquatable<Instrument> 。

Answer 2

就对象而言，总是比诸如整数之类的原始值更好。 如果明天您的需求发生了变化，而您不仅需要ID，还可以轻松地将其添加到Instrument对象中，而不用更改所有代码。

Answer 3

GetInstrumentInfo(int instrumentId);

这可能意味着客户端代码必须具有：

GetInstrumentInfo(instrument.Id);

不要让您的方法的用户担心这样的小细节。 让他们只传递整个对象，让您的方法完成工作。

没有看到任何主要的性能劣势。 传递Int还是引用实际对象。

假设您想多开发一些GetInstrumentInfo，它比一个Int更容易访问整个对象。

Answer 4

您需要问自己的第一件事是：

“如果我有两个ID == 53的工具，那是否意味着它们绝对是同一工具，无论如何？或者在有意义的情况下它们可能不同？”

假设答案是“它们都是相同的。如果其他任何属性都不相同，则可能是错误，或者是因为一个这样的对象是一个接一个地获取的，并且它将尽快解决自身（当任何处理线程正在使用旧的工具时）。 ，停止使用它）”，然后：

首先，在内部，只要使用发现的便利即可。 您很可能会发现这一直都是int的，尽管您通过坚持将Instrument传递给方法而获得了一些类型安全性。 如果所有Instrument构造都是通过工厂方法访问的internal或private构造函数进行的，并且代码的用户无法使用其id与系统中的任何内容都不匹配的伪造Instrument进行构造，则尤其如此。

这样定义平等：

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]
}

无论您追求什么，对性能的影响都是相同的。 提供给用户的代码将是类型安全的，并确保他们不会传入假值。 选择的实现可能只是出于其他原因而觉得更方便的实现。

由于在内部将乐器本身用作键不再花费您更多的钱，因此我仍建议您（上述三个选项中的第一个）将其用作类型安全，并使其难以传递虚假值然后也将适用于您的内部代码。 另一方面，如果您发现一组调用仍然仅使用ID（例如，如果他们正在与仅ID表示含义的数据库层进行通话），那么更改这些位置对您而言将变得容易快捷，并且对用户隐藏。

如果用户适合，您还可以使用户能够将您的对象用作键并进行快速的相等比较。

Answer 5

您可以重载每个函数，一个函数需要一个工具，而另一个函数需要一个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];
}

这将为您提供足够的灵活性，以便当您遍历调用GetInstrumentInfo任何地方以将其更改为传递id时，当前代码仍将起作用。

至于您是否“应该”完全取决于您。 您将不得不权衡更改所需的时间以及在代码中进行更改的好处。