The outcome from #1 Learning Topic: Coordinator Pattern

Going with Andrey Panov Coordinator as it seems to offer the most flexibility and functionality:

• I like the use of closures to communicate between coordinator and controller
• I also like the use of factories to test
• If this becomes a problem this article has some nice options (delegates)
  Using closures with the coordinator pattern

Some seem to use Delegates for events between Coordinator and ViewControllers others use Closures, need to see why this is the case?

Using closures with the coordinator pattern

That allows to inject callbacks into a view controller rather than a specific coordinator. This has the effect of creating even more loose coupling than having a coordinator object or protocol, allowing us to replace coordinators with something else entirely if we wanted.

This technique of closure injection is nothing new – in fact, Apple even mentioned it in their WWDC 2016 presentation, Improving Existing Apps with Modern Best Practices. However, I think it has its limits: if you try to pass in more than a couple of closures it gets messy, and you should consider using a coordinator object or protocol instead.

Possibly use both?

Why do some of the examples use Factories?

• For dependency injection and easier mocking in tests
  • Dependency injection using factories in Swift
• To avoid singletons
  • Avoiding singletons in Swift
• To avoid Shared state
  • Using the factory pattern to avoid shared state in Swift