Extending modules

While making modules, it's likely that you want to make your modules extendable.

Simple module extending

Let's look at the real-world example. You're making a minigame system, and you want to extract common team handling to an abstract module class.

import net.hypejet.modules.Module;

public abstract class TeamModule extends Module<GameEnvironment> {
    // Common team handling
}

It's allowed, but let's dive into how it's going to work in this library.

If you create an implementation of TeamModule, let's call it ActualTeamModule, registering ActualTeamModule will also bind TeamModule to the same module instance.

This means that ModuleManager#getModule and related methods will return the same instance for both TeamModule and ActualTeamModule.

Furthermore, you can specify TeamModule as a dependency. The module manager will search for module instance that extends TeamModule, so in our case it will require ActualTeamModule.

What's more, you cannot register any other modules extending TeamModule.

That's it! If you want to make it possible to register multiple modules extending the same class, head to the next section of this wiki page.

Abstract modules

Now you're about to make an abstract module with the ability to register multiple implementations of it.

It's possible as well, thanks to the AbstractModule annotation.

See the foolowing example:

import net.hypejet.modules.annotation.AbstractModule;
import net.hypejet.modules.Module;

@AbstractModule
public abstract class ExampleAbstractModule extends Module<ExampleEnvironment> {
    // Contents of your module
}

You can create multiple implementations of ExampleAbstractModule and register all of them to be used by one module manager. However, you cannot depend on abstract modules or get them via ModuleManager#getModule, and that's because module instances are bound to all of their superclasses, until module manager encounters the first abstract module.

You can even make your abstract modules extend normal modules, but as the definition of abstract module makes clear, implementations of your abstract module will not be bound to superclasses of that abstract module.

Special case

However, there's one special case worth paying attention.

Let's say modules A, B2, C1, C2 aren't abstract, while B1 is. Module C1 extends B1, which extends A. Module C2 in turn extends B2, which also extends A.

You can register both module C1 and C2. C1 will be bound to C1 class only, but C2 will be bound to C2, B2, and A. In conclusion, you can register multiple modules extending module A, but only one of them can be bound to module A class, and others must extend it indirectly by using an abstract module.