在这种情况下，我应该选择组合还是继承？

考虑一个接口：

interface IWaveGenerator
{
    SoundWave GenerateWave(double frequency, double lengthInSeconds);
}

此接口由许多类实现，这些类生成不同形状的波（例如SineWaveGenerator和SquareWaveGenerator）。

我想实现一个SoundWave基于音乐数据而不是原始声音数据生成类的类。它会收到音符的名称和以拍子（不是秒）为单位的长度，并在内部使用该IWaveGenerator功能来创建一个音符SoundWave。

问题是，应该NoteGenerator包含IWaveGenerator还是应该从IWaveGenerator实现中继承？

由于两个原因，我倾向于合成：

1 -它让我注入任何IWaveGenerator的NoteGenerator动态。另外，我只需要一个NoteGenerator类，而不是SineNoteGenerator，SquareNoteGenerator等等。

2-无需NoteGenerator公开由定义的较低级接口IWaveGenerator。

但是，我发布此问题是为了听取对此的其他意见，也许是我没有想到的要点。

顺便说一句：我会说NoteGenerator 从概念上讲是an，IWaveGenerator因为它生成SoundWaves。

它允许我动态地将任何IWaveGenerator注入NoteGenerator。另外，我只需要一个NoteGenerator类，而不是SineNoteGenerator，SquareNoteGenerator等。

这是一个明显的信号，最好在这里使用组合，而不要继承SineGenerator或SquareGenerator或（更差）两者。但是，IWaveGenerator如果您稍稍更改了后者，那么直接从NoteGenerator继承便会很有意义。

在真正的问题在这里，它可能是有意义的有NoteGenerator与类似的方法

SoundWave GenerateWave(string noteName, double noOfBeats, IWaveGenerator waveGenerator);

但是没有方法

SoundWave GenerateWave(double frequency, double lengthInSeconds);

因为此接口过于具体。您希望IWaveGenerators是生成SoundWaves的对象，但是当前您的接口表示IWaveGenerators是仅根据频率和length生成SoundWaves的对象。这样更好地设计这样的界面

interface IWaveGenerator
{
    SoundWave GenerateWave();
}

并通过，a 或您想到的任何其他生成器的构造函数传递诸如frequency或的参数lengthInSeconds，或一组完全不同的参数。这将允许您创建具有完全不同的构造参数的其他类型的。也许您想要添加一个需要一个频率和两个长度参数的矩形波发生器，或者类似的东西，也许您想接下来添加一个至少包含三个参数的三角波发生器。或者，与构造函数的参数，和。SineWaveGeneratorSquareGeneratorIWaveGeneratorNoteGeneratornoteNamenoOfBeatswaveGenerator

因此，这里的一般解决方案是将输入参数与输出函数解耦，并且仅使输出函数成为接口的一部分。

NoteGenerator是否在概念上是IWaveGenerator无关紧要。

仅当您计划根据Liskov替换原理（即具有正确的语义和正确的语法）实现该确切接口时，才应从该接口继承。

听起来您的NoteGenerator可能在语法上具有相同的接口，但是其语义（在这种情况下，它所采用的参数的含义）将非常不同，因此在这种情况下使用继承会产生极大的误导性，并且容易出错。您在这里更喜欢构图是正确的。

2-无需NoteGenerator公开由IWaveGenerator定义的较低级接口。

听起来NoteGenerator不是WaveGenerator，所以因此不应实现该接口。

构图是正确的选择。

您有坚实的构图理由。您可能还需要增加继承。判断方法是查看调用代码。如果您希望能够NoteGenerator在期望的现有调用代码中使用IWaveGenerator，则需要实现该接口。您正在寻找可替代性的需求。无论从概念上讲，它是否是“是”波发生器，都不在话下。

既NoteGenerator可以实现该接口，也NoteGenerator可以具有一个内部实现（按组成方式）引用another的内部实现IWaveGenerator。

通常，合成会导致代码更具可维护性（即可读性），因为您没有复杂的替代来推理。您对使用继承时具有的类矩阵的观察也很重要，并且可能被认为是指向合成的代码味道。

当您有一个要专门化或自定义的实现时，最好使用继承，这里似乎不是这种情况：您只需要使用该接口即可。