Why static methods for making View Controllers and other components?

[tonyarnold]

What's the reasoning behind using:

static func makeViewController(_ userService: UserService) -> ProfileViewController {}

instead of a convenience initialiser:

convenience init(userService: UserService) { }

[srdanrasic]

I'm exploring structuring code into modules, something like

enum UserModule {}

// Views
extension UserModule {
    class SomeUserModuleSharedView {}
    class SomeOtherUserModuleSharedView {}
    ...
}

// View controllers
extension UserModule {
    class ProfileViewController {}
    class EditProfileViewController {}
    ...
}

// Binders
extension UserModule {
    static func makeProfileViewController {}
    static func makeEditProfileViewController {}
    ...
}

so a binder is a function on the module like UserModule.makeProfileViewController().

Convenience initialiser, however, does sound like a nice way to go. Let me explore it in a demo project that I'm making.

[danielt1263]

One good reason for using a static function instead of a convenience initializer is because then we have more control over the return value. The static function can return a UIViewController rather than a sub-class (to reduce the temptation of leaking the abstraction.) Also, the static function can return a tuple (UIViewController, Signal<Result>) which is handy when the child VC needs to communicate information back to the parent.