Today I Learned - Day 59 [디자인 패턴 - 1]
자, 금일 부터는 디자인 패턴에 대해서 설명해 보자.
다만, 디자인 패턴은 형식이 정해진 것이 아니라, 개발의 편의성과 효율 등을 높이기 위한 일종의 '경향'이라는 것을 주의하도록 하자. '이렇게 만들면 좋다'지, '이렇게 만들어야 한다'가 아니라는 것이다.
그런 만큼, 같은 디자인 패턴이라도 구현 방법이 한 종류가 아니라 매우 다양하다.
그러니, 본문은 참고용으로만 보고, 실제로는 본인이 고심하여 작성하여 보자.
[참고 URL - https://refactoring.guru/ko]
디자인 패턴 - 2 : https://lsu0503.tistory.com/123
Today I Learned - Day 61 [디자인 패턴 - 2]
이번에도 찾아온 디자인 패턴 정리 시간이다.금일에는 '생성'과 관련된 패턴을 정리해볼까 한다.[참고 URL: https://refactoring.guru/ko]디자인 패턴 - 1 : https://lsu0503.tistory.com/120 Today I Learned - Day 59 [디
lsu0503.tistory.com
파사드(Facade)
[참고 URL: https://refactoring.guru/ko/design-patterns/facade]
파사드는 은행 등의 '정면'을 의미하는 단어로, 파사드 패턴은 모듈 간의 복잡한 구성을 간소화 하기 위해서 이들을 아우르는 '보관함' 모듈을 활용하는 패턴을 말한다.
간단하게 모듈들을 public 변수로 들고 있어서 해당 모듈을 통해서 편하게 접근할 수 있는 구성 부터, 각 모듈을 이용한 복잡한 연산을 함수 하나로 정리하는 심화 구조 까지 존재하는 디자인 패턴으로, 이 패턴을 쓰냐 마냐에 따라서 코드의 길이가 큰 폭으로 달라진다.
아예 파사드 모듈 하나만 변수로 들고 있다가, 이 파사드 변수를 경유해서 여러 모듈을 활용하는 구성도 가능하기도 하는 등, 객체 지향에서 꽤나 중요한 위치에 있는 패턴.
작성 방법은 간단하다. 해당 객체와 관련된 class들을 모두 public 변수로 가지고 있는 class를 하나 만들면 끝.
그리고 싱글톤 모듈에서 이 보관함 클래스를 public으로 가지고있도록 한다던지 하는 방법으로 이를 편하게 접근할 수 있게 구성하면 된다.
여기서 더 나아가면 이 보관함 클래스에서 내부 모듈들을 복잡하게 활용하는 기능을 작성해 놓고 함수 하나로 Call 할 수 있도록 구성하는 것도 좋다.
전체적으로 '절차의 간략화'가 중점인 패턴.
브릿지(Bridge)
[참고 URL: https://refactoring.guru/ko/design-patterns/bridge]
다리(Bridge)라는 이름처럼, 객체의 구성 요소를 한 번에 묶어놓는 것이 아닌, 개별로 작성하면서 이를 포함관계라는 다리를 통해서 조합하는 패턴을 말한다.
흔히 설명할 때 도형 객체를 만들 때, 색상을 하위 모듈으로 구성하여 제작하는 방식으로 설명하는 경우가 잦은 패턴으로, 객체를 N^n으로 분기 구성할 수 있는 요소에서 쓰기가 좋은 패턴.
특히, 이렇게 하위 구성으로 넣은 뒤에 Enum값을 이용해서 동적 할당되도록 구성한다면 데이터파일 하나로 다종다양한 객체들을 양산할 수 있는 구성이기도 해서 기획적인 측면에서도 유용한 패턴이다.
[여담으로, 개인적으로 본인은 구성요소 전체를 개별 모듈로 만들고 이를 조합하는 방식으로 구성하는 편이다.]
작성 방법은 그냥 세부 요소 별로 별개 기반 class를 작성하고, 이를 상속받는 방식으로 실제 모듈을 작성한다.
이후 이를 목표 class에서 선택하여 적용하는 방식으로 작성하면 된다.
어찌 보면 FSM과도 유사점이 보이는 패턴이기도 하다.
커맨드(Command)
[참고 URL: https://refactoring.guru/ko/design-patterns/command]
커맨드라고 해서 명령을 내리는 그 커맨드라고 생각할 수 있는데, 엄밀히 말하자면 그건 아니다.
격투 게임에서 키 조합을 '커맨드'라고 부르는데, 커맨드 패턴의 커맨드는 바로 이 커맨드이다.
즉, 입력[요청] 자체를 객체화 시켜서 이를 Queue에 저장, 활용하는 방식이 바로 이것.
그 덕분에 엄밀히 말하면 커맨드 보다는 주문(Order) 패턴이라고 하는 것이 더 이해하기 쉬울 수도 있다.
[물론, 이미 이름이 정해져 있는 패턴인지라, 멋대로 바꿔서 부르진 말자. 본문에서는 이해를 돕기 위해서 바꿔 설명한 것이다.]
대다수의 액션게임에 있는 '선입력' 시스템이 이 커맨드 패턴을 활용하면서 입력값을 객체로 만들어서 큐를 통해서 제어하다 보니 자연스럽게 생기는 '특성'이다. 다만, 이 선입력은 제어에 대해서 세심히 세팅하지 않으면 조작감이 문자 그대로 나락으로 떨어져버리는 양날의 검에 가까운 특성이다.
그렇기 때문에 특정 상황에서는 입력을 받지 않는다거나, 특정 상황이 되면 큐를 비운다거나, 입력값에 가중치를 두고 우선순위 큐를 통해서 작동하도록 만든다거나, 입력 값에 최대 한도를 넣는다거나, 특정 조건에 맞춰서 입력값을 변경하거나 취소할 수 있게끔 한다거나, 연속 입력에 대한 처리 방법을 규정한다거나 하는 식의 추가 제어를 '반드시' 행하여야 한다.
대신, 적절하게 적용하면 '입력'의 가짓수를 획기적으로 늘리면서도 조작감을 어마어마하게 높여줄 수도 있기 때문에 액션게임을, 그것도 커맨드나 콤보 위주의 게임을 만들고자 하는 경우에는 매우 중요한 디자인 패턴이기도 하다.
가능하다면 직접 만들지는 않더라도 어떻게 하면 좋을지 구상 정도는 해 보는 것을 추천한다.
작성법은 상술했듯이, 입력 함수는 큐에 입력 객체를 넣도록 구성하고, 처리 함수에서 이 큐에서 입력 객체를 가져와서 작동하도록 구성하면 된다.
상술했듯이 다종 다양한 상황에 맞는 추가 제어를 넣어줘야 하긴 하나, 기본 형태는 이렇게 구성하면 된다.
다시 한번 말하지만, 디자인 패턴은 '정답'이 존재하는 영역이 아니다.
이러한 개념을 통해서 좀 더 효율적이고, 효과적이면서 편리한 구성을 만들기 위한 경험자들의 노하우라고 보는 것이 옳다.
그러니, 본인이 어떻게 하면 더 효율적으로, 더 효과적으로, 더 편리하게 개발을 할 수 있는 가를 고민한다면 그것이 디자인 패턴으로 직결되는 것이다.
그러니, 본인의 스타일을 갖추자. 그리고 갈고 닦자. 그러면서 더 나은 방법은 없는 지 고민해 보고, 확인 해 보자.
그렇게 한다면 자연스럽게 디자인 패턴도, 개발 실력도 일취월장 하게 될 것이다.