包装本机库时保持封装性

Question

我正在编写一个 C# 库来包装 Win32 API（waveOut... 系列函数），并且已经达到了我不确定如何管理我的不同部分之间交互的程度。代码而不破坏封装。到目前为止，我有这样的设置：

public class AudioDevice
{
    ...
    private WaveOutSafeHandle hWaveOut;
    ...
}

// All native method calls happen in wrapper methods here, providing
// uniformity of access, exceptions on error MMRESULTs, etc.
static class NativeWrappers
{
    ...
    internal static WaveOutSafeHandle OpenDevice(...) { ... waveOutOpen(...) ... }
    ...
}

// Native methods live in a class of their own, and are only called
// from NativeWrappers
static class NativeMethods
{
    ...
    internal static extern MMResult waveOutOpen(...);
    ...
}

这段代码中最重要的一点是设备包装的句柄对于设备之外的任何东西都是不可见的。

现在我想添加一个 AudioBlock 类，它将包装原生 WAVEHDR 结构和音频样本数据。我遇到的问题是，从现在开始，几乎所有我感兴趣的其他本机函数（waveOut[Un]PrepareHeader、waveOutWrite）都需要句柄和一个 WAVEHDR。看起来要么设备必须接触 WAVEHDR，要么块必须有权访问句柄。这两种方法都意味着某个类与它在概念上无权了解的事物进行交互。

当然，有几种方法可以解决这个问题：

1. 将句柄和/或WAVEHDR设置为内部的而不是私有的。

2. 将 AudioBlock 设为 Device 的嵌套类。

3. 有第三个类（我什至不愿意想到这个名字(foo)Manager），它维护（例如）从块到标头的映射，给定一个块，设备可以使用它帮助它在不接触块内部的情况下播放样本。

可能还有其他的；我希望如此:)我

对这些方法的反对（正确或错误）：

1. 从严格意义上来说，它们可能不是公开的，但使用内部成员对我来说似乎是一种逃避。什么是有效的实现细节对于图书馆中不需要它们的部分仍然是可见的。我一直在想“我想向任何使用或修改此代码的人展示什么界面？”

2. 这几乎在我的脑海中起作用。通过将块视为设备的“实现细节”，允许它依赖于设备的内部结构似乎更容易被接受。除了区块确实是一个独立的实体之外；它不绑定到单个设备，也不用于帮助实现设备的逻辑。

3. 这最接近我想要维持的分离水平，但开始误入过度设计的领域，就像我经常做的那样：P它还引入了一个人为的想法，即块必须从某个地方集中分配以保持映射完好无损。

那么，有人对（重新）构造这段代码有什么建议吗？有效的答案包括“你的反对#X是一个热气腾腾的瓦罐”，只要你能说服我:)预计到达时间：例如，如果你认为尝试强制执行这种事情最好由社交来完成手段（文档、约定）而不是技术手段（访问修饰符、程序集边界），请让我知道并指出一些参考资料。

Answer 1

从严格意义上来说，它们可能不是公开的，但使用内部成员对我来说似乎是一种逃避。

就我个人而言，我只是将包装器设为内部，并将整个类集视为单个公共 API。

我理解避免这种情况的愿望 - 它迫使您创建类，这在您的开发过程中违反了单一责任原则。

然而，从“外部”世界的角度来看，任何使用您的软件的人都会看到您提供的每个类都有一个单一的、明确的责任和一个单一的目的。该 API 至少可以与您所包装的 API 一样干净（考虑到托管代码，可能要简单得多）。

在这种情况下，我这样做的主要动机是实用性。是的，我同意您在此处尝试遵循的准则 - 但是，它们只是准则，只要准则不会造成弊大于利，就值得遵循。我赞扬您尝试使其尽可能保持干净和优雅，但不幸的是，听起来在这种情况下，尝试使此“更优雅”将导致更多代码，这将等同于降低可维护性。

我在这里坚持使用最短、最简单的解决方案 - 将本机包装器置于内部，这样您就可以在包装器类中获取所需的数据结构。只需记录您在做什么以及为什么。