Container with parent assembly

[Nikita2k]

Container with parent assembly

This PR contains changes & tests for creating container with parent assembly.

Why?

Assume you have ApiManager, ViewController1 and ViewController2 in TabBar application. Both controllers asks API for some data. To implement this scheme we can create the following container hierarchy:

• RootContainer (where ApiManager lives)
  • Controller1Container (all specific dependencies for VC1)
  • Controller2Container (all specific dependencies for VC2)

Later you decide to make a new feature: background upload (or tracking user location, etc). You have bunch of classes, that are responsible for that. Now you have two options:

1. Create BackgroundUploadContainer and put all dependencies there
2. Put all code to RootContainer

Both of them are not so good and shiny:

1. You can't add it to current hierarchy, as you might want to add new "service" and it will lead you to multiple inheritance
2. Your RootContainer will be soon a 10-screen-height file with lots of dependencies

Solutions?

We can have a RootAssembly = RootContainer + BackgroundUploadContainer. But with that solution it's impossible to have Controller1Container knowing about both of them (no container constructor accepts Assembler).

I propose to add such a constructor.

[houndci-bot]

Valid Docs Violation: Documented declarations should be valid. (valid_docs)

[yoichitgy]

Thank you for your pull request with the enhancement and unit test👍 I would like to merge it.

Before merging the PR, I have a small suggestion. I think the requirement can be achieved by adding initializers to Assembler without modifiying Container like the following code.

public convenience init(parent: Assembler) {
    self.init(container: Container(parent: parent.container))
}

public convenience init(assemblies: [AssemblyType], propertyLoaders: [PropertyLoaderType]? = nil, parent: Assembler) throws {
    try self.init(assemblies: assemblies, propertyLoaders: propertyLoaders, container: Container(parent: parent.container))
}

As discussed in PR #35, I would like to keep Container independent from Assember for future source layout. What do you think about the suggestion?

[yoichitgy]

This pull request relates to the following StackOverflow question:
http://stackoverflow.com/questions/34715871/swinject-migrating-to-assemblies

[yoichitgy]

@mowens, do you have any comment?

[mowens]

I like the idea of keeping the Container free of the Assembler. When I came up with the proposal for the Assembler the idea was to create a seamless way to organize components across multiple files. I think what @Nikita2k is looking for is a means to compose Assembler with another Assembler where their containers can have a child/parent relation. This can be done without the need to change the Container class. So I agree with @yoichitgy suggestion where you can compose an Assembler with another Assembler

This way access to the actual container is still restricted to only the Assembler which prevent manually adding service/component definitions outside of the scope of an AssemblyType. Then using @Nikita2k example, you could do something like this:

let rootAssembler = Assembler(assemblies: [
    RootAssembly(),
    BackgroundUploadAssembly()
])

let controllerAssembler = Assembler(assemblies: [
    Controller1Assembly(),
    Controller2Assembly()
], parent: rootAssembler)

[yoichitgy]

Thank you @mowens😃

[Nikita2k]

@yoichitgy @mowens Great idea, guys. Dagger (dependency injection for Java) has similar structure. I will reopen pull request (in fact, I have to revert my commits and start from scratch). Lets keep this one open if other people have suggestions :)

[yoichitgy]

Thanks @Nikita2k for accepting our idea.

I think you can force-push to the same branch to update this PR without creating a new PR😀

git push --force origin feature_container_with_parent_assembly

[houndci-bot]

Valid Docs Violation: Documented declarations should be valid. (valid_docs)

[houndci-bot]

Valid Docs Violation: Documented declarations should be valid. (valid_docs)

[Nikita2k]

@yoichitgy I can't push to your repo:) We usually keep unsuccessful PR too, but if you like, I pushed changes here

[yoichitgy]

Thank you @Nikita2k for updating the PR. Now I see your intention creating a new PR. I just don't have a policy to keep PRs before editing, so your update to this PR is ok.

I will investigate the messages from Hound CI, then will merge your PR. I've not updated my SwiftLint to 0.5.5 yet, and don't know why the code docs violating the lint.

[yoichitgy]

Hound CI looks still using SwiftLint 0.4.0. This PR branch in my local environment has no violation with SwiftLint 0.4.0. It looks Hound CI incorrectly reported in this PR.

[yoichitgy]

Thanks @Nikita2k for the enhancement. I was wondering whether the initializers should be convenience or not when I wrote the past comment. Your definitions are better because the initializers are not optional ones just for convenience. The argument order is also good regarding the default parameter 😃