Question about DIContainers

[Reak45]

Hello,
I got a question. Did you write an article about Container patter you are using? Or could you provide me with a link to the article that maybe you based on when creating DI? I really love the pattern, but there are things that I don't fully understand. I would be more than happy for any info :)

Cheers!

[nalexn]

Hey, I currently don't have an article about that, though I can clarify a few things for you:
DI stands for Dependency Injection, there are quite a lot of articles about this and also about Dependency Injection Containers.
The DIContainer used in this project serves the same purpose - injection of dependencies, so you could easily toggle between using a real module or a fake one for tests / offline demo mode / faster development.

My implementation is intentionally simplified (if you compare it to fully-fledged DI libraries like Typhoon), although, to my taste, those libraries are overkill.

[Reak45]

while the service owning it can signal at any time

So the Service its self should contain ** PassthroughSubject** right? For example: ToDoService should expose 3 publishers: "onAdded", "onUpdated", "onDeleted"? And everywhere I want to get the info about any of these events occur I would pass that service in the right parts of the app?

[nalexn]

Yep, or you can refactor this into one publisher that delivers an enum:

enum RecordUpdate {
    case added(<params>)
    case updated(<params>)
    case deleted(<params>)
}

[Reak45]

you can refactor this into one publisher that delivers an enum

This is brilliant! I haven't thought of that! Thank you.

I like this approach but I believe it has one downside. ToDoService must be alive from the start of the app, am I correct? I would need to subscribe to the exact instance to be able to be notified. So I cannot use UseCases (single short lived parts of business logic that do only one thing and when it's done they are being destroyed). I would say that maybe static publisher would solve the problem but it sounds like a terrible idea. The only else thing that comes to my mind is to use NotificationCenter. But I think that this not good either.

[nalexn]

The lifetime of the signal source and recipients is crucial when designing this. I don't know the specifics of your case, but if you want to not rely on the objects' lifetime you can introduce a stand-alone object that'd work as a duplex - taking the events and broadcasting them. This is how NotificationCenter works, basically. Beware though, this may lead to a spaghetti code easily.
If you decide to go this path, you can simply write your own NotificationCenter that just has a public PassthroughSubject for a specific type of events. This Object would be alive, but won't be sending anything on its own

[Reak45]

Thank you for all the answers. I look into this! Have a great day!