patternjavaMinor
Pending method invocation for a game
Viewed 0 times
methodinvocationgamependingfor
Problem
I need to do pending methods invocation in Java (Android) in my game project. A method represents actions in a scene.
Maybe you're familiar with
Please suggest the best way of doing this, by considering memory usage (maybe PermGen too), performance, ease of coding, and bug freedom.
Using switch-case
I need to add each method call in switch-case.
Using for-loop and annotation/reflection
Like the above, but make coding easier (except in defining constants).
```
public class MethodContainer {
private static final int METHOD_0 = 0;
...
private static final int METHOD_100 = 100;
public void invoke(int index) {
for (Method m : MethodContainer.class.getMethods()) {
MyAnnotation annotation = m.getAnnotation(MyAnnotation.class);
if (annotation != null && annotation.value() == index) {
try {
m.invoke(this);
break;
} catch (...) {
...
}
}
}
}
@MyAnnotation(METHOD_0)
private void method0() {
...
}
Maybe you're familiar with
Context.startActivity in Android, which is not suddenly starting the activity, but statements below it is still executed before starting the requested activity. I've found 3 ways, but I'm not sure which one should I choose by considering the performance and PermGen issues (actually I don't know whether Android has PermGen issue if there are so many classes). These methods will not be called very frequent, may be once in 5 seconds, but may be they will be very many (there are so many scenes).Please suggest the best way of doing this, by considering memory usage (maybe PermGen too), performance, ease of coding, and bug freedom.
Using switch-case
I need to add each method call in switch-case.
public class MethodContainer {
public void invoke(int index) {
switch (index) {
case 0:
method0();
break;
.
.
.
case 100:
method100();
break;
}
}
private void method0() {
...
}
.
.
.
private void method100() {
...
}
}Using for-loop and annotation/reflection
Like the above, but make coding easier (except in defining constants).
```
public class MethodContainer {
private static final int METHOD_0 = 0;
...
private static final int METHOD_100 = 100;
public void invoke(int index) {
for (Method m : MethodContainer.class.getMethods()) {
MyAnnotation annotation = m.getAnnotation(MyAnnotation.class);
if (annotation != null && annotation.value() == index) {
try {
m.invoke(this);
break;
} catch (...) {
...
}
}
}
}
@MyAnnotation(METHOD_0)
private void method0() {
...
}
Solution
Your first example (switch-case) is so poorly thought of in the Object Oriented community that there is a refactoring designed specifically to replace it with your third implementation: Replace Conditional With Polymorphism.
To be honest, I would have never thought of your second implementation. It isn't completely heinous, though I would probably use the constructor to create an array of method objects that you can index into directly - rather than run through a for loop every time you want to make a call.
Between a revised second implementation (array with annotation/reflection) and the third implementation (inner classes) I would personally be more fond of the "inner class" version. I don't think that memory or performance is going to be a factor at this level and I think the third, inner class, version is much more readable (at least in Java - in other languages, you could implement something like the second approach directly).
To be honest, I would have never thought of your second implementation. It isn't completely heinous, though I would probably use the constructor to create an array of method objects that you can index into directly - rather than run through a for loop every time you want to make a call.
Between a revised second implementation (array with annotation/reflection) and the third implementation (inner classes) I would personally be more fond of the "inner class" version. I don't think that memory or performance is going to be a factor at this level and I think the third, inner class, version is much more readable (at least in Java - in other languages, you could implement something like the second approach directly).
Context
StackExchange Code Review Q#13780, answer score: 2
Revisions (0)
No revisions yet.