Add javadocs for ComponentRegistry and related.

This commit is contained in:
asofold 2013-01-26 08:03:33 +01:00
parent 4324d4fe74
commit 9bb8687a88
4 changed files with 21 additions and 6 deletions

View File

@ -1,5 +1,13 @@
package fr.neatmonster.nocheatplus.components;
/**
* A ComponentRegistry allows registering components, that then are delegated to where they belong.<br>
* Notes:
* <li>Implementations should somehow specify when components can be registered and when they are unregistered automatically.</li>
* <li>Implementations should somehow specify what components can be registered.</li>
* @author mc_dev
*
*/
public interface ComponentRegistry {
/**
* Convenience method to add components according to implemented interfaces,
@ -7,7 +15,7 @@ public interface ComponentRegistry {
* For the NoCheatPlus instance this must be done after the configuration has been initialized.
* @param obj
*/
public void addComponent(final Object onj);
public void addComponent(final Object obj);
/**
* Remove a registered component. <br>

View File

@ -1,10 +1,14 @@
package fr.neatmonster.nocheatplus.components;
/**
* ComponentRegistry:
* <li>Supported components: Listener, TickListener, PermStateReceiver, INotifyReload, INeedConfig, IRemoveData</li>
* <li>Registering components should be done during onEnable or any time while the plugin is enabled, all components will be unregistered in onDisable.</li>
* <li>References to all components will be held until onDisable is finished.</li>
* @author mc_dev
*
*/
public interface NoCheatPlusAPI extends ComponentRegistry{
}

View File

@ -1,7 +1,7 @@
package fr.neatmonster.nocheatplus.components;
/**
* Can be registered with the TickTask.
* Can be registered with the TickTask. Ensure that registered objects get unregistered before the plugin gets enabled again. You can ensure it by using NoCheatPlusAPI to register a TickListener.
* @author mc_dev
*
*/

View File

@ -46,6 +46,9 @@ import fr.neatmonster.nocheatplus.hooks.APIUtils;
* Originally intended as temporary or intermediate design, this might help reorganizing the API at some point.<br>
* However i could not yet find a pleasing way for generic configuration access for a centralized data management (all in one),
* so this might just be a workarounds class for coping with the current design, until somehow resolved in another way.
* <hr>
* ComponentRegistry:
* <li>Supported: IRemoveData</li>
* @author mc_dev
*
*/