抽象工厂是否引入了紧耦合

Question

我有一个场景，我认为我没有严格地对接口进行编码。 假设我有一个接口（在某些程序集中）

public interface IFoo
{
    void GetSomething();
    void SaveSomething();
}

现在，我有一个实现（在其他程序集中）

public class FoodB : IFoo
{
   public FoodB(Guid guid, IFoodBConfig config)  //IFoodBConfig is defined in same library where FoodB exists
   {
      ...
   }
}

所以，基本上实现需要guid和config

现在，我有一个客户（在其他程序集中）希望使用 IFoo，类似于

public class Client
{
    public Client(IFoo foo)
    {
       ...
    }
}

DIP 表示必须在组合根中提供实现，并且客户端不得实例化对象本身。不错不错。

现在，组合根或 IoC 容器决定注入 FoodB 作为具体实例，但它没有 'guid' 的值，因为它仅在运行时可用。

所以，我们决定使用抽象工厂。

public abstract FooFactory
{
    public abstract IFoo GetFoo(Guid guid, IFoodBConfig config);
}

现在，提出了几个问题

a) 客户端构造函数必须修改为接受FooFactory 而不是IFoo，这意味着客户端已经决定使用什么实现。在我看来，这使得软件紧密耦合

b) 即使客户端构造函数被修改为接受FooFactory，IFoodBConfig 混凝土也必须提供给构造函数，这将使客户端引用存在FoodB 的库。

c) 工厂声明和实现将放在哪里？将FooFactory 放在声明IFoo 的库中是不正确的，因为工厂与IFoo 无关。由于同样的原因，将FooFactory 放入FoodB 库中也不正确

d) 简而言之，使用抽象工厂意味着交换实现的灵活性已经消失，因为客户端是绑定到 FoodBFactory 的目录。

这种方法是否不正确，或者这是我们必须忍受的一些限制？

Answer 1

这个问题需要解决的几个问题。

1. FooFactory 不是 Abstract Factory 的示例，至少在 GoF 术语中如此。
   Abstract Factory != 名为 Factory 的抽象类。
2. 组合根不需要在编译时具有其所有参数。现代 IoC 容器都应该支持运行时参数。

a) 正如@dbugger 所评论的，将客户端耦合到抽象类与耦合到接口没有什么不同。

b) FooBFactory 实现或 IoC 容器都可以预先配置为 FooBConfig。然后客户端只传递其运行时 guid。

c) FooFactory 与IFoo 直接相关，因为它的目的是返回IFoo 的实例。确实，它的方法的返回类型是IFoo。

d) 之所以存在灵活性，是因为 IoC 容器可以将 Factory Method 的不同实现注入客户端，允许客户端在不了解产品实现或用于实例化它的工厂实现的情况下获取不同的产品。

如果您愿意将客户端耦合到 IoC 容器，则客户端可以直接将容器用作工厂，从而消除额外的工厂接口。