Open Radar

 
Summary:
Dependency injection is the best way I know to structure object oriented applications. Storyboards would be a nice way to structure parts of the UI layer of said applications, if only they didn’t make using dependency injection extremely painful.

I thought subclassing NSStoryboard and overriding instantiateControllerWithIdentifier would be a reasonable way to work around storyboard taking away control of view controller instantiation. It wouldn’t allow me to use Swift’s “let” properties, but at least it would be one place where I could inject the view controllers’ dependencies after they had been instantiated.

But even that doesn’t work. As soon as you’re using child view controllers with NSSplitViewController or NSTabViewController, you lose even that post-instantiation handle on them. You have to subclass the container view controllers and contort your code to dig through the embedded view controllers to find what you want, so you can thread your dependencies to their final destination.

Compared to just using a single factory object to instantiate your objects, it’s so horribly complicated that any benefits storyboards would bestow by reducing the amount of code soon disappear in the dependency management spaghetti.

Simplest solution, to me, would seem to be to just allow the programmer to give a factory object or function as a parameter to the storyboard factory method. If given, it would be responsible for instantiating the objects.