接口设计-参数选择

Question

Situation

最好是有一个或几个参数为预期的过程提供更多的信息，还是应该有更多的特定参数来提供足够的信息？

当参数变得更具体时，如果需要使它们更具体的过程--包括业务规则/逻辑或与非常特定的类紧密耦合--是否还应该这样做呢？

示例

在接口的情况下：

public interface IQuestion
{
    // Specificity in Interface parameters increases Coupling right?
    void MyFunction(IPrincipal user, string destination);

    // Is this any better? It allows me to be more flexible in what I'm doing
    // Inside these functions but it also makes them even more coupled right?
    void MyFunction(ControllerContext context);
}

问题：

有没有一般的规则或情况，特别是用一种方式比另一种方法更好呢？

Answer 1

是否最好有一个或几个参数为预期的过程提供更多的信息？

“够多了”是这里的红旗。

当你在商店付款时，你不会把你的整个钱包都给收银员，这样收银员就会从里面取出现金。收银员其实不需要知道你的钱包是什么样子，也不需要看你孩子的照片，顾客可能根本没有钱包。程序应该以类似的方式工作。

通过传递包含(或可能包含)更多必要信息的捆绑值，您正在破坏封装(称为函数可以访问与其无关的数据)，另外，它混淆了设计，因为没有明确的约定。不明显的是，被调用的代码实际上需要什么，它不需要什么，仅仅通过查看它，您必须查找它的实现才能找到答案。您不知道您的ControllerContext究竟对MyFunction有什么用处。它可能会在运行时爆炸。

当然，如果User和destination结合在一起，那么它们只是属于一个类，在任何地方都没有必要将它们分开。但有一种“超过足够”的观念表明情况并非如此.

Answer 2

这是个平衡。

一般来说，拥有特定的接口比一般的接口要好。函数不应该知道更多的知识，他们需要知道工作。

但是，通常情况下，只有在一个地方使用的大量接口是不好的。

因此，您需要在为您的需要创建特定接口和使用现有接口之间取得平衡，即使它们并不十分适合。谢天谢地，如果你做得对，这种情况很少出现。如果您的对象很简单，并且有一个单独的责任，那么函数只需要该对象的一部分是不常见的。