저도 둘다 쓰고 있는데, 쓰다가 뭐가 더 좋을까 고민하게 되네요.
특히 확장성, 유지보수용이성으로 보자면,

예를들어,
Mode가 나중에 10개가 추가되었다고 한다면,
좀 달라질까요?
아니 100개가 추가된다면
어떨까요?

1번의경우,
장점:
enum 항목만 추가하면 된다.
단점:
enum을 변경하게 되면, 기존 GameState 클래스가 변경되어서 Open-Closed 원리에 위배됩니다.
그럼 enum 정의를 GameState 클래스 밖에다 선언하게되면,
GameState 클래스는 외부선언값인 enum 에 의존성을 갖게 됩니다.

2번의 경우,
장점:
확장에 용이하다.의존성이 없다.
단점:
클래스를 그만큼 생성해야한다.


전 2가 그나마 좋다고 생각해서 2를 만들다가
클래스가 많아지다보니,
compare 할 경우 조건문을 많아지고
추가적인 작업들이 있는데
이게 맞는것인가? 의문이 듭니다.

개인적으로 1번의 경우 enum 이 추가된다는 가정을 안해서요..
만약 불가피하게 추가된다면 OCP 에따라서 기존 클레스의 enum 을 수정할게 아니라
GameStateExtended extends GameState {
public enum ExtendedMode {
Arena(GameState.Mode.Arena),
PvP(GameState.Mode.PvP),
PvE;

private final GameState.Mode originalMode;

ExtendedMode(GameState.Mode originalMode) {
this.originalMode = originalMode;
}

public GameState.Mode getOriginalMode() {
return originalMode;
}
}
}

식으로 확장을 하던가

Wrapper 로 계속 감싸야 하지 않을까요?

자바는 enum 이 object 인가 보군요. ;;;
하긴 swift 도 enum 이 object 였던것 같네요.

예시를 게임으로 든것이지만,
다른분야의 클래스일경우 Mode 가 천차만별일수 있습니다.
그럴 경우에 대한 고민이네요.

저도 항상 옛날 코드 보고 리팩토링을 하는데
왜 처음부터 이렇게 설계안했을까 하는 후회를 종종합니다.
그런 불평, 고민에서 나온 의문이었습니다.

확장성과 유연성을 고려안한다면
1,2 번 큰차이는 없고 오히려 1번이 더 편할수가 있습니다.


하지만,
우리는 언제 어떻게 요구사항이 변경될지 모르기에..
1번의 경우는 Single Responsilbity 원칙과 Open-Closed 원리에 위배됩니다.

예를 들어서,
GameState 클래스 내부에 DoSometing 함수를 만들어야 하고,
그 안에 Mode 별로 다르게 처리 해야 한다면,
1번의 경우

void DoSomthing (){
if(mode == Arena){
// do something in arena

}
else if ( mode == PvP ){
// do somthing in PvP
}
}

나중에 Mode가 더 추가가 될경우,
저 함수내부에 또 추가해야 합니다.
이건 Single 책임에 위배됩니다.

2번의 경우는

public abstract class GameState(){
public int id;
public string name;
public abstract void DoSomething();
}

public class Arena:GameState(){
public void DoSomething(){
// do something in Arena
}
}

public class PvP :GameState(){
public void DoSomething(){
// do something in PvP
}
}

이렇게 해버리면,
클래스와 코드는 딱 정해진 한가지 모드에 대해서만 관리가 됩니다.