Question

这里有一篇文章： http://msdn.microsoft.com/en-us/library/Ee817667%28pandp.10%29.aspx

tut的第一部分用抽象类实现了这个模式。第二部分显示了Interface类的示例。但本文中没有任何内容讨论为什么这种模式宁愿使用抽象或接口。

那么你会给出什么解释（一方面的优势）？不是一般的，而是针对这种精确的模式。

然而，Interface的众所周知的好处是松散耦合，那么为什么它不适用于这种模式呢？如果不是为什么所有微软的东西都使用接口呢？

我对缺乏答案感到惊讶。似乎人们知道如何做事，但不是真的为什么。

Answer 1

如果你考虑一下，抽象基类就像是一个部分实现的接口。因此，如果您具有将由工厂创建的所有类共享的某些标准功能，请使用抽象基类。如果您没有任何实现，只需使用一个接口。

Answer 2

你在想错了。无论是使用接口还是抽象类，都应该在创建实体时做出决定。稍后，当您决定构建它时，您将使用抽象工厂模式。

他们只是表明它可以处理任何形式的抽象。接口通常被视为“更好”，因为它允许通过不强制构造函数而不使用继承链接来进行更松散的耦合。但是，使用工厂返回接口也很少见，因为通常你想让人们能够注入自己的接口实现，这在传统上不是工厂模式的作用（尽管它肯定可以）< / p>

使用我能想到的接口有一个特定的好处;您可以使用同一个类实现两个不同的接口。这是一个（相当愚蠢的）例子：

interface IProvideInfo {
  string Get();
}
interface IProvideConnectionString : IProvideInfo { }
interface IProvideCurrentUserName : IProvideInfo { }

class CurrentContextProvider : IProvideConnectionString, IProvideCurrentUserName  {
  string IProvideConnectionString.Get() {
    return ConfigurationManager.ConnectionStrings["db"];
  }
  string IProvideCurrentUserName.Get() {
    return _currentUserName;
  }
  string _currentUserName;
  public string SetCurrentUserName(string s) {
    _currerntUserName = s;
  }
}

public class InfoProviderFactory {
  CurrentContextProvider _provider = new CurrentContextProvider()
  public IProvideInfo GetProvider(string key) {
    return _provider;
  }
}

探索工厂设计模式

2 个答案: