- 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
Modifier and TypeInterfaceDescriptionstatic interface
TheDestroyable.DestroyAutomaton
interface 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 aComponent
has been destroyed, then invoking any of thatComponent
instance's methods (except thedestroy()
method) must throw anIllegalStateException
as by definition a once destroyedComponent
is in the state of being destroyed which is irreversible.- Throws:
DestroyException
- in case destroying a component caused problems. This is aRuntimeException
as destroying a component should always succeed and aDestroyException
should 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 theDestroyException
in the method signature when implementing this method!
-