Pull to refresh

Comments 2

Вопрос — В чем принципиальное отличие данного подхода от одной выделенной очереди (NSOperationQueue) с выставленным ограничением на число параллельных тасков? В чем бенефит своей очереди, планировщика и ранлупа?
В статье описываются все составляющие паттерна исключительно в иллюстративных целях. Разумеется, нет никакого смысла реализовывать очередь, планировщик и ранлуп самостоятельно. NSOperationQueue вполне может подойти в качестве базового блока для реализации паттерна, но сама по себе она его не реализует. Чтобы паттерн состоялся, необходимо гарантировать следующее:

  1. Объекты используют прямые вызовы друг к другу только при условии, что с ними проассоциирована одна и та же очередь. Если она не проассоциирована вообще, то тогда считается, что они должны исполняться в контексте главного потока.
  2. Если с объектами проассоциированы разные очереди, то вызов метода должен происходить опосредовано через исполнение NSOperation.
  3. Никакие 2 операции в одной очереди не должны исполняться параллельно. Т. е. либо в качестве underlyingQueue объекта NSOperationQueue должна быть serial queue, либо максимальное количество параллельно исполняемых операций должно равняться 1.

Ну и, конечно же, в production-коде крайне желательно обеспечить автоматическую проверку исполнения этих трех пунктов.
Sign up to leave a comment.