通过实现接口创建单例类有什么好处？

如果我有象下面这样的界面，通过实现接口创建单例类有什么好处？

public interface IMethods 
    { 
    void M1(); 
    void M2(); 
    }

然后我想通过上面的接口继承来创建一个单独的类，那么什么是在重新使用单例类，以及如何的情况下有什么好处？

来源

2014-03-13 user584018

我不完全确定你在问什么，但如果你问“作为单例实现这个接口有什么好处”，答案与singleton总是提供的好处是一样的：“保证一个实例不管它使用了多少个地方“。单例存在以强制实例访问vs静态类和方法/属性的类的单个实例。示例实现：

public class Methods : IMethods 
{ 
    // Singleton instance 
    private static readonly IMethods _instance = new Methods(); 

    // Private constructor to enforce singleton 
    private Methods() 
    { 

    } 

    // The instance getter 
    public static IMethods Instance 
    { 
     get 
     { 
      return _instance; 
     } 
    } 

    public void M1() 
    { 

    } 

    public void M2() 
    { 

    } 
}

，将在这里软管你的东西是事实Instance属性未曝光的IMethods接口上，所以得到它需要的实例类型是Methods而不是IMethods哪种类型的失败继承接口的目的。

通常，人们使用依赖注入框架将接口实现的生存期设置为singleton AKA共享实例。它更“OO友好”。

来源

2014-03-13 16:42:04 Haney

对'Instance'属性的访问可以隐藏在知道单例的'MethodsFactory'后面，但返回一个'IMethods'。正如你所说，这通常是由大多数DI容器免费提供的。 –

好点@AdamHouldsworth，没有考虑到这一点。仍然比DI框架更紧密地耦合。 – Haney

没有比DI框架更耦合的了，你要么加上你的'MethodsFactory'或你的Ninject'内核。获取（）'。所有的东西都可以被平等地抽象出来，DI只是给你免费的东西，而不是穷人的方法。 –

单身人士方面只是IMethods合同的一个实施，给你的单身模式的好处，假设这是你需要的。

通过接口暴露单例的好处是消费者不需要关心它是如何实现的，只是它实现了是，他们可以使用它。在以后的日子里，如果您突然需要一个常规实例而不是单例实例，那么您可以在不影响用户的情况下进行更改。

^{DI容器发生这种情况的频率非常高，您通常可以将绑定的生命周期配置为单例作用域。}

如果您直接使用单例并且从未真正使用该接口，那么在接口中几乎没有用处。如果单身人士正在使用，而不需要将其限制为单个实例，那么采用单身模式几乎没有用处。

来源

2014-03-13 16:43:42

请你可以请张贴一些示例代码实时情况？ – user584018

不需要，它将是一个标准的单例实现，它也会实现您的接口。额外的位将使用DI容器或工厂模式来返回'IMethods'。 –

通过实现接口创建单例类有什么好处？

回答

相关问题