Hmm... Computer programs consist of two basic units; data and code. Data is accessed statically via named variables and named functions and dynamically through pointers and function pointers. In object oriented programming, the things called objects are bundles of data with operations associated with them. Objects combine data and code into one variable or pointer.
If you have N objects and 1 effect but the effect require extra state data which is not stored in the original objects, you still need N places to store the extra state data even though there is only 1 effect. Function pointers are stateless.
There are three ways to fix it.
1) Take the state data out of the effect and put it into the object it
affects. (Use one object and one function pointer.)
2) Leave the effect state data in the Effect object. Reference the affected object int the effect object and vica versa. (Use one additional object per effect/entity pair.)
3) Merge the state data for all effects into the super class of the class it affects. (Use one object and bad design practices.)
To simplify the following definitions, assume that static variables are not used. (Mutable global variables are bad practice anyways.)
Data variables store values and do nothing on their own.
Functions represent code. They do nothing without data to work on.
Objects store both of the above.
Objects have an implicit
this reference. If you rely on having that reference as your code does, you are using your class as an object not a "function pointer".
1 2 3 4 5
| public enum Effect implements Whatever {
public abstract void doEffect(Object affectedObject); } |
1 2 3 4 5
| public class Thing { public abstract void doEffects(); public abstract void doEffect(EffectType effect); } |