通过仅使用原始类型/委托来实现松散耦合

Question

我有一个关于松散耦合和接口的概念/理论问题。

因此，使用接口的一种方法可能是封装某个构造函数所需的参数：

class Foo
{
    public Foo(IFooInterface foo)
    {
       // do stuff that depends on the members of IFooInterface
    }
}

因此，只要传入的对象实现了契约，一切都会起作用。根据我的理解，这里的主要好处是它可以实现多态性，但我不确定这是否真的与松散耦合有关。

为了论证，我们可以说 IFooInterface 如下：

interface IFooInterface
{
   string FooString { get; set; }
   int FooInt { get; set; }

   void DoFoo(string _str); 
}

从松散耦合的角度来看，在上面的构造函数中不要使用 IFooInterface，而是像这样设置 Foo 不是更好吗：

class Foo
{
    public Foo(string _fooString, int _fooInt, Action<string> _doFoo)
    {
       // do the same operations
    }
}

因为说我想删除将 Foo 的功能移植到另一个项目中。这意味着其他项目也必须引用 IFooInterface，添加另一个依赖项。但这样我就可以将 Foo 放入另一个项目中，它准确地表达了它工作所需的内容。显然我可以只使用重载的构造函数，但是为了论证我不想和/或不能修改 Foo 的构造函数。

最显着的缺点（至少对我来说）是，如果你有一个带有一堆原始参数的方法，它会变得丑陋且难以阅读。因此，我想到创建一种包装函数，它允许您仍然传递接口而不是所有原始类型：

    public static Func<T, R> Wrap<T, R>(Func<T, object[]> conversion)
    {
        return new Func<T, R>(t =>
        {
            object[] parameters = conversion(t);

            Type[] args = new Type[parameters.Length];

            for (int i = 0; i < parameters.Length; i++)
            {
                args[i] = parameters[i].GetType();
            }

            ConstructorInfo info = typeof(R).GetConstructor(args);

            return (R)info.Invoke(parameters);
        });
    }

这里的想法是，我可以取回一个函数，该函数采用符合以下条件的某个接口的实例 ： Foo 的要求，但 Foo 实际上并不知道有关该接口的任何信息。它可以像这样使用：

public Foo MakeFoo(IFooInterface foo)
{
    return Wrap<IFooInterface, Foo>(f => 
       new object[] { f.FooString, f.FooInt, f.DoFoo })(foo);  
}

我听说过关于接口应该如何实现松散耦合的讨论，但我想知道这一点。

不知道一些有经验的程序员是怎么想的。

Answer 1

在您最初的示例中，您非常接近 参数对象 模式，尽管它更常用这里是一个简单的类（通常具有自动属性），没有接口的额外抽象。

通常，当您听说将接口传递给构造函数时，它并不是要替换原语，而是作为依赖项注入的一种形式。我们不直接依赖 MyFooRepository，而是依赖 IFooRepository，这将消除与特定实现的耦合。

Answer 2

我的第一个想法是您没有为 FooString 和 FooInt< 的设置器提供 Action 和 Action /代码>，分别。 IFooInterface 的实现可能具有与这些 setter 相关的规则，并且可能需要访问接口上未公开的其他实现细节。

同样，您还应该接受 Func 和 Func：IFooInterface 的实现可能有以下规则：随着时间的推移，FooString 和 FooInt 是什么。例如，DoFoo 可能会重新计算这些值；你不能假设它们只是传递到永远不会改变的字段。

更进一步，如果 getter、setter 或 DoFoo 需要访问公共状态，则函数和操作在创建它们时需要关闭同一组变量。那时，您将做一些心理体操来理解变量的生命周期和代表之间的关系。

这种状态和行为的配对正是类所表达的，而实现细节的隐藏正是接口所提供的。将这些概念分解为其组成元素当然是可以实现的，但这也破坏了通过将成员与类型分组而获得的连贯性。

换句话说，你可以给我面条、酱汁、蔬菜和汉堡，但那不是意大利面和肉丸:-)