- All Known Subinterfaces:
Component,ComponentComposite,ComponentComposite.ExtendedComponentComposite<CTX,,CON> ConfigurableComponent<CTX>,ConfigurableLifecycleComponent<CTX>,ConfigurableLifecycleComponent.ConfigurableLifecycleAutomaton<CTX>,Destroyable.DestroyAutomaton,DigesterComponent<J>,InitializableComponent,LifecycleComponent,LifecycleComponent.LifecycleAutomaton,LifecycleComponent.UncheckedLifecycleComponent
- All Known Implementing Classes:
AbstractComponentComposite,AbstractComponentComposite.ExtendedCompositeComponentImpl,ConfigurableLifecycleAutomatonImpl,LifecycleMachine,LifecycleMachine.ManualLifecycleMachine
Component in order to provide
destroy facilities. No exception is thrown as destroy must work always!
The "decompose()" method Decomposable.decompose() differs from the
"destroy()" method destroy() in that "destroy()" shuts
down the component in memory, whereas "decompose()" also tears down external
resources such as files or DB schemas. This means that with "decompose()" all
external data will be lost, as with "destroy()" external data will be kept
(in terms that it makes sense for the actual implementation).
In case a Component has been destroyed, then invoking any of that
Component instance's methods (except the destroy() method)
must throw an IllegalStateException as by definition a once destroyed
Component is in the state of being destroyed which is irreversible.
ATTENTION: In case you intend to provide destroy() functionality to
a plain java class which is not intended to be a mature Component,
then please just implement the Disposable interface from the
refcodes-mixin artifact. This semantically underlines your intentions more
clearly (not being a Component and reduces dependencies to the
refcodes-component artifact.
-
Nested Class Summary
Nested ClassesModifier and TypeInterfaceDescriptionstatic interfaceTheDestroyable.DestroyAutomatoninterface defines those methods related to the destroy life-cycle. -
Method Summary
-
Method Details
-
destroy
void destroy()Destroys the component. External resources might stay untouched! This should always be possible and must not throw any exception. In case aComponenthas been destroyed, then invoking any of thatComponentinstance's methods (except thedestroy()method) must throw anIllegalStateExceptionas by definition a once destroyedComponentis in the state of being destroyed which is irreversible.- Throws:
DestroyException- in case destroying a component caused problems. This is aRuntimeExceptionas destroying a component should always succeed and aDestroyExceptionshould only be thrown in case of obvious malfunctioning and the philosophy of "fail early!" without forcing a method to declare an according checked exception! You may omit theDestroyExceptionin the method signature when implementing this method!
-