인프런 커뮤니티 질문&답변
작성한 질문수
Indicator와 SelectionAction 및 SearchAction 간의 관계에 대해 질문있습니다.
작성
·
8
0
좋은 강의 잘 듣고 있습니다. 감사합니다.
강의 코드를 면밀히 분석해보고 다양한 상황을 고려해봤습니다.
현재는 SelectionAction과 SearchAction들의 로직들이 Indicator의 로직에 제한된 느낌이 들었는데요.
현재 Indicator는
[모양]: 원형 및 원뿔 검색
[방향]: 원뿔의 경우 isAttachIndicatorToRequester에 따라 스페이스를 누른 시점에 방향이 고정
이처럼 제한 되다 보니 SelectTarget이나 SearchArea들의 내부 로직을 작성할 때 현재의 Indicator를 고려해서 작성 해야 되는 상황이 나옵니다
즉, 예를들어 사각형, 캡슐, 또는 구 형태의 Indicator라던가 마우스를 따라 회전하는 Indicator 등 로직들이 서로 상이합니다.
이렇게 다양한 Indicator들을 구현한다고 했을 때 이미 만들어둔 SelectionAction이나 SearchAction에서 Indicator들에 맞춰 로직을 분기 처리하는 방식이 될거같더라구요.
그래서 생각을 해봤는데 어차피 Indicator에 따라서 체크 로직이 다르다면 Indicator 내에서 체크 로직을 담당하는게 좋을거같다고 생각했습니다.
1) SelectionAction과 SearchAction에서 각각 범위 체크를 해야 되는 시점에 Indicator에게 정보를 넘겨준다.
2) 각 Indicator들은 받은 정보를 토대로 해당 Indicator에 맞춰 실제 범위 체크를 처리하고 그 결과를 SelectionAction 및 SearchAction에게 반환한다.
이렇게 하면 SelectionAction이나 SearchAction는 더 이상 수정할 것 없이 Indicator 만 구현해서 갈아 끼우면 되는 모듈로 사용할 수 있다고 생각이 듭니다.
하지만, SelectionAction과 SearchAction가 직접 범위를 체크 해야 하는 책임을 가지는 거였다면, 제가 말씀드린 설계는 책임 분리가 잘 못된 걸로 보여집니다.
따라서 질문 드릴 사항은
1) 위와 같은 설계 방식이 책임 분리나 다른 문제가 되는 방식일까요?
2) 또는 더 좋은 설계 방식이 있는지 궁금합니다.
감사합니다.
답변 1
0
수강해주셔서 감사합니다.
1) 제안하신 설계(Indicator가 범위 체크를 담당)가 책임 분리에 어긋나는가?
네, 단일 책임 원칙 관점에서는 조금 어긋납니다. Indicator의 본질적인 책임은 View/UI입니다. 플레이어에게 범위를 보여주는 역할이죠. 여기에 물리적인 충돌 체크나 거리 계산 같은 Logic를 넣게 되면, View와 Logic이 섞이게 됩니다. 거기다 이렇게 되면 나중에 '화면에 인디케이터는 안 띄우지만, 사각형 범위로 적을 찾는 스킬' 같은 것을 만들 때 곤란해집니다. 시각적 표현이 없는 데도 Indicator 객체를 생성해야 하는 모순이 발생하기 때문입니다.
2) 현재 방식
말씀하신 것처럼 "현재 코드가 원형/원뿔에 제한되어 있어서 새로운 형태를 추가하려면 로직이 꼬이지 않을까?"라고 충분히 우려하실 수 있습니다. 하지만 현재 강의의 구조는 이미 형태 확장을 고려하여 설계되어 있습니다.
IndicatorViewAction 클래스의 ShowIndicator(..., object range, ...) 함수를 보시면 매개변수 타입이 float가 아니라 object로 되어 있죠? 제가 이 값을 object로 선언해둔 이유가 특정 형태에 구애받지 않고 유연하게 데이터를 넘기기 위함입니다.
예를 들어, 사각형(Box) 범위 스킬을 새로 추가한다고 가정해 보겠습니다.
BoxSearchAction (로직): 내부에서 사각형 크기(
Vector3 extents)를 가지고Physics.OverlapBox같은 물리 연산을 알아서 처리합니다. 그리고 Indicator를 띄울 때는 자신이 가진Vector3값을RangeProperty의 반환값으로 넘겨줍니다. (SelectTarget class 참고)BoxIndicatorViewAction (뷰): 넘어온
object매개변수를 다시Vector3로 캐스팅해서 화면에 사각형을 그려주기만 하면 끝입니다. 꼭 BoxSearchAction이아니라도 Range로 Vector3를 return하는 SearchAction은 이 IndicatorView와 호환이 되는겁니다. 물론 View에 설정하는 Indicator 자체도 박스 형태를 구현할 수 있는 Indicator Prefab을 설정해야겠죠.
이렇게 하면 Action은 물리 연산만, Indicator는 시각 효과만 완벽하게 분리되어 담당하게 됩니다(Action - IndicatorView - Indicator 구조). 기존 코드를 뜯어고칠 필요 없이, 새로운 Action과 View 클래스를 파생시키는 것만으로 무한히 확장할 수 있는 구조인 것이죠. 좀 더 타입 안정성을 지키고 싶다하면 object가 아니라 IndicatorData 같은 구조체나 클래스를 만들어 넣기는 것도 괜찮습니다.
감사합니다.