【问题标题】:Do I use NSNotifications too much我是否过多使用 NSNotifications
【发布时间】:2015-07-16 13:39:49
【问题描述】:

我最近发现在我的 iOS 应用中进行自定义布局时使用 NSNotifications 的好处。我现在使用它们来发送数据而不是使用委托。例如,我在一个控制器中有一个UIScrollView,它改变了另一个view controller 中的图片的alpha,所以我只是在滚动视图滚动时发送通知,例如

func scrollViewDidScroll(scrollView: UIScrollView) {

        let userInfo = ["ScrollView":scrollView]
        NSNotificationCenter.defaultCenter().postNotificationName("scrollViewScrolled", object: self, userInfo: userInfo)
}

并在另一个视图控制器中观察这一点。我知道NSNotifications 的性能并不昂贵,但考虑到我使用它们的程度以及我与它们一起发送的数据,我想知道这是否会被视为不好的做法。

【问题讨论】:

    标签: ios swift uiscrollview nsnotificationcenter nsnotifications


    【解决方案1】:

    这是一个关于应用设计的好问题。通知提供了一种非常松散的耦合,如果不同的组件彼此不直接相关,它会派上用场。

    在我看来,大多数时候使用通知是一个糟糕的选择,无论是基于糟糕的设计还是懒惰。如果您查看您的代码,很难说出它是如何连接的,谁负责什么等。此外,谁处理通知的方式非常不灵活。例如,假设您想在另一个地方重用您的一个视图控制器——它可能不想触发这些通知。现在下一个代码异味指日可待。您开始修补通知处理或数据只是为了让它运行并消除副作用。

    这并不是说通知不好。它们有它们的用途,它可能在这里和那里都是合适的。只是在大多数情况下,从长远来看,丑陋的快速 hack 会让事情变得很臭(而且很难调试)。

    【讨论】:

      【解决方案2】:

      IMO 它们应该用于谨慎的事件,例如表示某事已经完成。 不建议使用它们在发生变化时发送连续的数据流,即使不会影响性能。

      它们提供了非常松散的耦合,但是仅仅为了提供松散耦合而使用它们来提供非常松散的耦合在我看来并不是一个好的设计,它走得太远了,已经从一种设计模式变成了一种设计反模式。 如果没有必要也没有好处,那么让代码的不同部分松散耦合是没有意义的。

      【讨论】:

        【解决方案3】:

        NSNotification 应该用于通知另一个实体有关更改,而不是传递数据。你可以通过 NSNotification 传递一个对象来告诉接收者通知是关于什么的。

        如果接收者收到通知,比方说,设置已更改。接收者可以根据传递的参数检查到底发生了什么变化并采取相应的行动。

        例如,如果数据已到达,您只需通知数据已到达,然后使用共享资源获取真实数据。共享资源可以是单例、数据库或其他任何东西。希望这能让你明白。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2013-02-19
          • 1970-01-01
          • 1970-01-01
          • 2023-03-15
          • 2012-03-19
          • 1970-01-01
          相关资源
          最近更新 更多