3

在过去的 6 年里，我一直是一名 Java 程序员，从今年年初开始，我对游戏编程产生了兴趣。所以，我认为从一个流行的游戏开始是个好主意，我用 Java 实现了游戏 Ms. Pac-Man。我可以说我的实现看起来与原始游戏大约 90% 相似，并且我尝试使用尽可能多的设计模式和最佳实践，因为这只是一个学习编写基本 2D 游戏代码的个人项目。

现在我完成了编码，我意识到我有 19 个接口和只有 17 个类！所以我开始怀疑我是否可能过度使用接口。

这是我使用的一些类/接口的示例：

类- FullGame（实现 FullGameInterface 和 FullGameObservable）

类- View1（实现 FullGameObserver）

Interface - FullGameInterface（基本功能方法：恢复、暂停、播放等）

接口- FullGameObservable（允许注册视图以获取更新通知）

接口- FullGameObserver（由游戏的 2 个不同视图实现以接收通知）

我是否过度使用接口？

你有什么意见？

4

4 回答 4

9

如果要更改实现，请使用接口。

对于像 FullGame 对象这样的东西，您可能不需要该接口。

如果您要更改 FullGame 的功能，那么您可以考虑制作一个接口，以便您可以切换为 FullGameInterface 实例化的对象。

编辑 2：仅在需要时使代码更复杂。如果您认为需要接口，请先停止。使用您已经拥有的课程。（但是当你使用它时，尽量让调用者远离实现细节。）一旦你有了第二个类似的类，你就可以弄清楚什么是真正的接口以及什么是实现。如果您的调用者仍然需要难以放入公共接口的实现细节，那么您就没有将它们保持得足够干净。

编辑以获得更完整的答案：

接口对于将访问对象（接口）的方法与实际对象（实现）解耦很有用。这适用于几种情况：

  1. 您拥有这些方法的多个实现，具有相同的语义和通用操作，但具有不同的底层实现。例如，List、ArrayList和LinkedList。 List是允许许多基于集合的方法接受 anArrayList或 a的通用接口LinkedList。该Collection接口允许对所有集合进行类似的安排。
  2. 出于架构原因，您需要将接口与实现分开。例如，您可以在一台机器上拥有调用对象，而在另一台机器上拥有实现对象。调用机器上的代理实现了通过网络调用真实对象的接口。该接口意味着调用者不必知道其中的区别。Java RMI 做到了这一点。
  3. 您需要能够修改调用对象的方式。例如，取一个接口Image和两个实现者，FileImage并且FileImageProxy. 代理FileImage按需加载并将对Image接口的调用传递给实际对象。客户永远不知道也不关心他们是如何获得图像的，或者它是否真的加载了；他们只知道有一个Image并且可以使用它。
于 2009-10-02T14:50:49.080 回答
4

如果您控制了代码并且只有一个实现，则说明接口毫无意义是一个好兆头（尽管如果您想进行测试，它可能很有用）。请记住，内部类也是类。

接口的多重继承以及实现通常是一个坏主意。

于 2009-10-02T15:02:52.853 回答
2

接口很好。拥有很多它们不是问题。

特别是如果您只实现了您的第一个游戏。如果你重用代码库来构建更多游戏，你可能会得到更多的多态性，因为你会重用接口。但是在这一点上，如果实现中的方法比接口中的方法多，那么接口是有目的的——它们向客户端隐藏实现细节，从而被迫遵守接口，启用多态性，这是 OO 的真正好处。

于 2009-10-02T15:03:37.360 回答
1

我经常使用界面来充实我的设计。我对它们进行了彻底的记录，这迫使我仔细考虑班级的职责。API 和类的内部之间总是存在一些区别，因此即使您（还）没有多个实现，指定接口通常也没有什么坏处。

于 2009-10-02T17:22:40.097 回答