Question

假设我正在定义一个实现两种不同视图的游戏类：

interface IPlayerView {
    void play();
}

interface IDealerView {
    void deal();
}

游戏在玩游戏时看到的视图，以及经销商在处理游戏时看到的视图（即，玩家无法进行经销商操作而经销商无法进行玩家行动）。游戏定义如下：

class Game : IPlayerView, IDealerView {
    void play() { ... }
    void deal() { ... }
}

现在假设我想让玩家可以玩游戏，但不能处理它。我最初的想法是，而不是

public Game GetGame() { ... }

我有类似

的东西

public IPlayerView GetGame() { ... }

但经过一些测试后，我意识到，如果我稍后尝试这段代码，它会起作用：

IDealerView dealerView = (IDealerView)GameClass.GetGame();

这样可以让用户充当经销商。

我担心多少？你通常如何处理这种模式？我可以改为制作两个不同的类，也许是一个“主要”类，即经销商类，它将作为玩家类的工厂。通过这种方式，我可以完全控制我想传递给公众的内容。另一方面，这使得一切变得比这个原始设计更复杂。

由于

Answer 1

首先，您正在尝试创建一个负责两个松散相关事物的类。我会在至少两个类中拆分此实现。如何将玩法“玩”给玩家，无论如何都应该在你的设计中调用它？

其次，你太担心了。接口和设计功能（如模式）等语言功能无法保护您（或其他开发人员）。如果有人想要滥用它，他们会（我认为这就是所谓的“黑客”）。它们可以让您的生活更轻松，您的代码更易于维护，消耗和可测试。

总会有一种滥用代码的方法。如果不是通过铸造，而不是反射。只要放下它，专注于建立“下一件大事”。

Answer 2

为Views创建一个实现类，然后将View Object传递给Factory Object并使用该Factory获取相应的视图。明天如果你需要再实现一个视图，那么你就可以轻松地进行增强。

Answer 3

我认为通过使用两种不同的方法play（）和deal（）可以获得很多，因为那时你并没有真正做任何运行时多态性。

概念上你需要的是一个play（）方法，但是对于Player和Dealer类有不同的实现。从高级别来看，经销商和玩家都在玩游戏，因此play（）方法，但他们如何实际玩它是不同的，经销商处理（卡）和玩家下注。

因此，与Georgy所说的一致，最好更改设计并使其更合乎逻辑，更简单。我通常在开始时尽可能简单，但无论如何它们往往会因为过载而负担过重未来迭代的过程。