1

我一直难以理解如何抽象接口以包含它们的整体效果，但仍然处理细节：

例如，

interface iAudio 
{
    iInput input;
}

其中 iInput 可以是来自各种事物（声卡、文件等）的输入。

iAudio 不关心它的输入来自哪里，只要它可以获取数据。所以 iInput 抽象了输入。到目前为止我很好。我可以有不同的东西来实现 iInput 插入，但似乎很难弄清楚在这之后要做什么。

我显然可以编写代码来做类似的事情，if (input is InputFile) ...但这似乎适得其反。（但这是对我有意义的方式）

我知道但对我来说似乎很难的另一种方法是尝试让 iInput 有适当的方法来获取数据，例如，

interface iInput
{
    byte[] GetData();
}

然后让不同的类实现这个，例如 InputFile 或 InputSoundcard。虽然它看起来太抽象了，并且没有提供很多做任何事情的能力。（也许我可以获取数据，但使用 InputFile 我需要指定文件名，而 InputSoundcard 将是其他设备特定信息。那么，我最终仍将使用第一种情况。

也许这基本上是正确的方法？感觉不对。希望我的例子足够清楚来证明这个问题。

4

2 回答 2

0

您想要这样的界面的原因是因为音频代码不需要关心输入的类型。

不会消失，但它在那个类之外。

在某些时候，有一些代码选择了一些输入，但并没有全部与音频代码混淆。

更新：

确实有很多方法可以设计特定的应用程序。知道如何处理它需要时间，并且不能保证学会它。还要记住，会有错误，没有办法绕过它:)

检查这本 SOLID 电子书 - http://lostechies.com/wp-content/uploads/2011/03/pablos_solid_ebook.pdf，它会有所帮助。

于 2013-07-02T12:43:25.320 回答
0

iInput 接口对我来说是正确的。我想对你所说的做出反应，这对你来说似乎是唯一真正的问题：

“也许我可以获取数据，但使用 InputFile 我需要指定文件名，而 InputSoundcard 将是其他设备特定信息”

是的。但这是特定于方法的信息，还是特定于实例的信息？对我来说，不带参数的 getData() 方法是完全可以接受的，并且每个实现都将使用实例属性中可用的任何参数。

所以，是的，这是正确的做法，或者至少我是这么认为的:)

于 2013-07-02T12:39:51.543 回答