Instead of having (mutable) actions that may/may-not need to ever run (e.g., JPA entities combined with logic), we should separate it out so that we have a container instead.
Action:
has data on what it is (clientType, and other data; e.g. a SceneItemVisibilityAction has OBS client type, and has data on scene name, scene-item name, and that it should be shown (instead of hidden)
can be mutated / persisted to Hibernate etc. / is JPA entity
RunnableAction:
has a copy of the data in the action, except for clientType; instead of client type, has the actual instance of the Client it needs
has a copy of the CommandRequestContext; e.g. data about who is executing, arguments, etc.
is runnable; implements how it should use the client
Immutable; will be executed, must be thread-safe
We could then create a Factory that takes a (mutable) Action and CommandRequestContext and creates a runnable version for the specific request context.
It would create an immutable clone of the Action (as the Action provided may likely be mutable considering it will come from Hibernate / be JPA compliant)
It would have a dependency on ActionClientFactory so it can find the right client to inject given the Action's type.
Instead of having (mutable) actions that may/may-not need to ever run (e.g., JPA entities combined with logic), we should separate it out so that we have a container instead.
Action:
RunnableAction:
We could then create a Factory that takes a (mutable) Action and CommandRequestContext and creates a runnable version for the specific request context.