我应该将应用程序范围的对象传递给需要它的对象，还是应该使用单例？

Question

在我的具体情况下，我正在通过嵌套视图控制器向下传递一个“facebook”对象（即 MonoTouch.FacebookConnect.Facebook 的一个实例），并且它正在向项目中添加一些不错的代码。对象在 AppDelegate 中实例化后始终只有一个实例，并且在应用程序中的大多数视图控制器中都有使用。所有使用 facebook 对象的视图控制器在开头都有这样的内容：

public class MyViewController : UIViewController
{
    Facebook facebook;

    public MyViewController (Facebook facebook)
    {
        this.facebook = facebook;
    }
    // ...
}

...除了顶层视图控制器，对象被实例化的地方。

还有一种情况是它“通过”嵌套视图控制器，只是为了将它传递给使用它的更深层嵌套的视图控制器。

我知道单例通常不受欢迎，并且违反了 OOP 原则。我希望代码易于维护。我是否采取了正确的方法，或者单身人士会在不影响代码质量的情况下做到这一点？

Answer 1

我会不惜一切代价避免单例。您的方法鼓励松散耦合，并允许您通过模拟对象来提高可测试性（如果您从具体实现转换它）。它通常会添加更多代码，但您应该在应用程序中具有更好的可测试性。这允许您使用 IoC 容器并利用依赖注入。网络上和 StackOverflow 上有许多关于此类主题的精彩文章和帖子。

也许你的单身人士可能看起来像这样：

public class MyViewController : UIViewController
{
    public MyViewController ()
    {
    }

    public void Foo()
    {
        FaceBookSingleton.Instance.DoSomeAction();
        FaceBookSingleton.Instance.Something = 4;
    }
}

您如何围绕Foo() 进行测试？如果您引入了重大更改，您怎么能更快地知道？你怎么知道你的依赖图是什么样的？像这样测试代码更难。不要指望人们浏览您的代码库来尝试找出他们是否破坏了某些东西。通过编写可测试的代码帮助他们和你自己。

现在也许看看这样的东西：

public interface ISocialMediaWidget
{
    ISocialMediaWidgetResponse DoSomeUnitOfWork();
}


public class ConcreteSocialMediaWidgetService
{
    protected readonly ISocialMediaWidget socialMediaWidget;

    public ConcreteSocialMediaWidgetService(ISocialMediaWidget widget)
    {
        this.socialMediaWidget = widget;
    }

    public ISocialMediaWidgetResponse Foo()
    {
        return socialMediaWidget.DoUnitOfWork();
    }
}

围绕上述内容编写测试要容易得多。您还可以模拟来自每个接口的响应以创建各种测试。

public void SocialMediaWidgetTest()
{   //pseudo code
    var testService = new MockObject(ConcreteSocialMediaWidgetService(MockObject_of_ISocialMediaWidget));
    Assert.Equals(someImplementation_of_ISocialMediaWidgetResponse, testService.Foo());
}

Answer 2

首先，单例在很大程度上只是其他完全可接受的 OO 策略（如“工厂”和记忆化）的替代语法。

这是一个语法问题，以及每种语法在您的组织中的含义。如果您这样做，您的组织是否暗示可能会对产品 MyClass.Current 进行一些工作？

public class MyClass
{
  public static MyClass Current
  {
    get
    {
      if (SomeSortOfCache['MyClass.Current'] == null) {
        // do something to get populate it.
      }
      return SomeSortOfCache['MyClass.Current'];
    }
  }
}

或者，您的组织是否更喜欢这样的东西：

public class MyClass
{
  public static MyClass GetCurrent()
  {
    if (SomeSortOfCache['MyClass.Current'] == null) {
      // do something to get populate it.
    }
    return SomeSortOfCache['MyClass.Current'];
  }
}

或者，如果您想将其视为工厂，请调用方法BuildMyClass() 或CreateMyClass()。在引擎盖下，机制大致相同。这主要是您的组织对每种语法 + 命名约定的假设问题。

其次，您已经确定您只希望或需要允许 的一个实例存在。所以，我建议使用一种可以优雅地促进这一点的模式，并且使用最少的代码。

Answer 3

在这种情况下，单例似乎是更好的解决方案，因为您可以消除大量重复代码，并在快速构建应用程序时增加更改的灵活性。

单例也可以充当 Facebook 对象的中介，让应用程序的各个部分更易于使用。

任何本质上受限的资源都适合通过单例访问。

Answer 4

我更喜欢使用单例方法，因为您总是只需要一个实例。