1

这是一个独立于语言的问题。从概念上讲，最好为接口（合同）而不是特定实现编码。我理解这种做法的优点没有问题。

但是，当我真正在那种实践中编码时，我的类的用户有时需要转换接口以满足实现该接口的特定类提供的特定功能的特定需求。

我知道无论是在我这边还是在用户那边，一定有问题，因为接口应该公开所有可能需要的方法/属性（在 c# 的情况下）。

代码库很大，用户就是客户。在任何一方进行更改都不会特别容易。

这让我想知道使用接口作为参数和返回类型的一些缺点。人们可以列出这种做法的缺点吗？如果您知道如何解决它，请提供任何解决方案。

非常感谢您启发我。

编辑：更具体一点：假设我们有一个名为 DbInfoExtractor 的类。它有一个公共方法GetInfo，如下：

public IInformation GetInfo(IInfoParam);

其中 IInformation 是由 VideoInfo、AudioInfo、TextInfo 等特定类实现的接口；IInfoParam 是由 VidoeInfoParam、AudioInfoParam、TextInfoParam 等特定类实现的接口；

显然，根据传入方法 GetInfo 的具体对象，DbInfoExtractor 需要采取不同的操作，因为可以合理地假设对于不同类型的信息，提取器会考虑不同的方面集（例如 {size, title, date}用于视频，{标题，​​作者}用于文本信息等）作为搜索键并以不同方式搜索相关信息。

在这里，我看到了两个选项： 1，使用 if ... else ... 根据 GetInfo 方法接收的参数类型来决定实际采用什么。这当然很糟糕，因为避免这种情况是我们使用多态性的原因之一。

2、我们应该调用IInfoParam.TakeAction()，而IInfoParam的每一个具体实现都有自己的TakeAction()方法来实际从数据库中搜索找到对应的信息。这个选项看起来更好，但仍然很糟糕，因为它不应该是采取行动搜索和查找信息的参数；它应该是 DbInfoExtractor 的责任。

那么如何将 TakeAction 委托回 DbInfoExtractor？（实际上我写了一些代码来做这个，但它既不标准也不优雅。基本上我将参数类嵌套在 DbInfoExtractor 中，以便它们可以调用 DbInfoExtractor 的各种版本的 TakeAction。）

请赐教！谢谢。谢谢。

4

1 回答 1

0

为什么不

public IVideoInformation GetVideoInformation(VideoQuery);
public IAudioInformation GetAudioInformation(AudioQuery);
// etc.

看起来这里不需要多态性。

如果需要，查询类型是Query Objects 。它们可能不需要是接口；他们对数据库一无所知。一个简单的参数列表（可能只是 ID）可能就足够了。

问题是客户有什么，他们想要什么？那是你的界面。

Switch 语句和强制转换是一种气味，通常意味着您违反了Liskov 替换原则。

于 2013-04-03T17:09:04.187 回答