Guice pattern for long lived dynamic 1:1 relationships?

60 views
Skip to first unread message

Ryan Leach

unread,
Jun 13, 2018, 9:32:30 PM6/13/18
to google-guice
In Minecraft, specifically SpongeAPI, There are a series of Worlds that are simulated in game.

These worlds are generally in an update cycle known as 'ticking' that world.

Worlds are generally loaded at startup, and unloaded on shutdown, but can have repeating life cycles on the client, where someone might return to the main menu, then load up a new game save loading new worlds.

On the server, worlds can be added or removed by the admins while the game is running.

If I have Services(onStart,onEnd,onTick) and virtual game entities (not true entities that live in the world, but are simulated like they are by the services that depend on world)

And SpongeAPI provides World load/unload events.

What would be the best strategy using Guice to manage dependencies on worlds?

If I listen for the world load/unload events, I have the world needed pretty easily to do the DI manually for the services, but under Guice I'm not sure how to correctly bind classes that need a world, to be using the correct world?

Most Guice tutorials I've seen handle Request scopes, or application bootup, but never really multiple anonymous dependencies with a 1:1 relationship, that can be dynamically loaded / unloaded.

Or am I right in thinking this needs to be handled manually, and all Guice can do to help in this situation, is inject the world that I explicitly provide in a ReentrantScope (https://github.com/timboudreau/scopes) and somehow keep that scope around for children of the service?


Stephan Classen

unread,
Jun 14, 2018, 3:14:45 AM6/14/18
to google...@googlegroups.com

Scopes are surely a way to handle this situation. But Scopes are also hard to get right and they introduce a little "magic" because you need to know that a dependency is scoped. Because if you cache the instance you get from guice in a field it may not be the one you expect at a later state...

Therefore I like to make such things a bit more explicit. In your case I would create a Class called CurrentWorlds. Make that class a singleton and have it implement the following 3 methods:
- add(World world)
- remove(World world)
- Collection<World> get()

In you EventListener you can then add and remove worlds as they get loaded and unloaded and in your regular code you can always get the current worlds which is the collection of worlds loaded at that very moment.

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/a121d04e-7edc-46fc-b943-72e7427d7cc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages