This is why "States" suck:
What looks cleaner, this:
enum State {
CHOP,
WALK_TO_BANK,
WALK_TO_TREES,
BANK
}
@Override
public int onLoop() throws InterruptedException {
switch(getState()) {
case CHOP:
chop();
break;
case WALK_TO_BANK:
getWalking()....
break;
case WALK_TO_TREES:
getWalking()....
break;
case BANK:
bank();
break;
}
return 0;
}
private State getState() {
if (whatever) {
return State.BANK;
} else if (whatever) {
return State.WALK_TO_BANK;
} else if (whatever) {
return State.WALK_TO_TREES;
} else {
return State.CHOP;
}
}
Or this? :
@Override
public int onLoop() throws InterruptedException {
if (whatever) {
chop();
} else if (whatever) {
getWalking()....
} else if (whatever) {
bank();
} else {
getWalking()....
}
}
Unless you are completely blind, I think you would agree the second is far more readable and much less code. Instead of having to look in a different method for the conditions, they are right there next to the code I am executing when they're satisfied. I don't need to maintain a redundant enum either.
People will argue that using "States" are cleaner, however this is probably because they are not making use of the DRY principle, not making effective use of methods etc. and without "States" they would just throw all of their code into onLoop.
As for "Tasks" or "Nodes", they have the exact same issues as "States" and more. People will argue they are cleaner because now each of their actions is in a nice self contained class, and the condition is in there too. However using this pattern you have now even less of an overview of the script as you did with states, and it's even harder to debug.
Consider this:
List<Node> someRandomAssNodes = new ArrayList<>();
@Override
public int onLoop() throws InterruptedException {
for (Node node : someRandomAssNodes) {
if (node.validate()) {
node.execute();
}
}
return 0;
}
The problem with this is that now in order to figure out how this script will execute I need to go into each of those Node classes, in the same order that you add them to the List and look at each of the validate methods and try and figure out how they all fit together:
I mean, that pattern is pretty bonkers don't you think?
Instead of having:
WalkToBankNode
ChopNode
BankNode
WalkToTreesNode
DoSomeOtherShitIDKNode
Why not just just write something simple, and easy to understand like my previous example.
IF your script gets massively complex, then you should be making use of OOP principles to simplify it. You still don't need to use a weird 'Node' or 'Task' pattern, you can have a generic banking class without needing to add a validate method inside of it, and you can have a mining class without having a validate method in there either.
Sorry if the some of the syntax is off, or I rambled.