개체의 상태가 다양하게 변하고 변한 상태에 따라 다양한 상태 정보가 발생할 경우에 대한 처리

개체가 다양한 상태를 가지고
그 상태에 따라 구조가 다른 상태 정보를 가질 경우
이런 상태 정보를 유형으로 개체의 필드에 모두 표현하는 것은
메모리 활용 측면에서 적절하지 않고 상태가 늘어날 수록 상태 필드가 계속 늘어나는 것은 좋은 구조가 아닌 것 같습니다. 특히 이런 개체들이 수천 개 수만 개일 경우 더더욱 더 그럴 것 같은데요,

이런 경우 여러분은 어떻게 상태와 상태에 따른 동작, 그리고 상태 정보를 구현 하나요?

3개의 좋아요

이런 고민을 하는 이유는, Rust의 경우 enum으로 개별 상태에 따라 독립적인 상태 정보를 유지할 수 있다는 것을 경험했기 때문입니다. 물론, Rust는 강력한 정적 언어기 때문에 각 상태에 따른 처리는 개별 분기 해서 처리하기는 합니다.

C#으로 접근하게 되면 디자인 패턴을 사용해서 각 상태에 따른 상태 정보의 처리를 상태 정보 처리 개체에 위임해서 처리할 수 있는데 이렇게 되면 어쨌든 구조적으로 복잡해지는 감이 있어서요.

다른 분들 의견은 어떠세요?

3개의 좋아요

저는 단순하게
상태 전체를 아우르는 부모 클래스 선언 후에 (State 정도가 되지 않을까요?)
여러 상태에 해당하는 자식 클래스를 (StateA…StateB 하는식으로…)
개체에는 State를 property로 보관한다
이정도만 겨우 생각해 냈어요.
물론 더 좋은 방법이 있지 않을까요??

3개의 좋아요

예. 구조적으로는 필요에 따라 좀 더 복잡하게 만들 수도 있겠지만, 객체지향적으로 그 방식이 아마 가장 많이 사용하는 방식이 아닐까 합니다. 사실 상태의 개수가 추가되거나 상태에 따라 행동이 추가 되거나 변경되는게 아니라면, 아마 C#에서는 베스트 케이스일 것 같습니다.

만약 상태의 종류가 계속 추가되거나 그에 따른 행동이 계속 구현되어야 한다면, 개체가 상태에 따라 행동을 하도록 규정하는 별도의 클래스를 만들 수 있겠죠.

그 개체를 사용하는 쪽에서는 상태행위를 담당하는 개체와의 인터페이스가 노출 되는게 꺼릴 수 도 있습니다. 보통, 이럴 때는 명시적 인터페이스를 통해 구현하면 좋습니다. 그러면 그 개체를 사용하는 쪽에서는 캐스팅 하지 않으면 노출이 안되니까요.

3개의 좋아요

그렇겠네요! 인터페이스로도 구현 할 수 있지 않을까 하고 막연하게 생각만 했었는데,
디테일하게 짚어주셔서 감사합니다.

2개의 좋아요