Home

Welcome to the Annotated-DI wiki!

Annotated DI adds Dependency Injection for Minecraft mods. A basic understanding of the Dependency Injection design pattern is helpful, and if you are looking to do anything advanced, knowledge of Guice will also be helpful, since that's what this is using behind the scenes. This is not just a repackaged version of Guice though, it also has some additions specifically to make this more Minecraft-friendly and developer-friendly.

So now for the important question that some may be asking,

why?

Or more specifically, why do this in a Minecraft mod when there are other ways to set things up already?

To start off with, my main public-facing use for this is designing the APIs for my mods. Specifically, I have my mods that use this keep the API as a separate source set containing (mostly) interfaces. There are a few times it may be useful to include a class (e.g. a handled exception class when some method in the interface throws it), but for the most part, only interfaces are exposed. Obviously, this approach may have to change a bit when dealing with content mods or other mods which have abstractions that extend Minecraft's files, but in general, I try to keep the APIs as abstract as possible.

I've found several advantages in developing my mods using this pattern.

1. Separation of concerns

By declaring the bare minimum in the public API of the mod as interfaces, I'm able to share only the necessary information for use at compile time and hide implementation details that shouldn't be relevant. This results in a stable API that modders can trust won't break, even if I change the underlying implementation. It also prevents modders from accidentally relying on any internal files that are subject to change.

2. API has no dependency on the implementation

With the API structure mentioned before, the interfaces don't care at all about the implementation, and are compiled without a dependency on (or access to) the implementation's files. This acts as a good way to avoid accidentally exposing internal files or implementation details through the API, which once again, helps create a stable, reliable API.

3. Clean design

This isn't to say this design is a surefire way to "magically clean up" the code. But it does help with considerations about how the code should work when you're just looking at the file and its exposed functions without a bunch of implementation details scattered around them. Specifically, a few things I try to look at are:

• Do these functions belong in this file? One file should be a group of related functions, so if something doesn't quite fit, it may belong somewhere else.
• Are these functions self-documenting? Ideally, function names should give a clear description of what the function does, and parameter names should be descriptive enough to understand what they are without digging through documentation.
• How easy will these be to use? The goal is to provide a simple exposed interface to allow other mods to focus on the interaction with your mod, not spend hours trying to wrap their head around how to do what they want to.