인프런 커뮤니티 질문&답변
작성한 질문수
만약 보드를 이용한 게임의 종류가 더 다양해진다면 어떻게 될 수 있을지에 대한 고민
작성
·
10
·
수정됨
0
안녕하세요, 열심히 강의를 수강 중인 4년차 백엔드 개발자입니다.
먼저 이렇게 퀄리티 높은 강의를 제공해주셔서 감사드립니다!
저는 4년차임에도 아직 리팩토링할 때 '관심사의 분리' , '같은 관심사끼리의 응집'에 대한 느낌을 체득하지 못해서 듣고 있습니다.
문득 SRP까지 강의를 들은 시점에 GameBoard를 보고 'GameBoard가 셀로 나눠진 보드판'을 의미하는 것이라면 현재 GameBoard는 '지뢰찾기'에 한정된 느낌인데, 나중에 체스, 오목, 장기와 같은 보드형 게임을 추가한다면 어떻게 바꿔야 할까를 고민해보게 되었습니다.
질문을 올리는 이 시점에는 GameBoard를 더 포괄적인 개념의 보드판으로 두고 상속을 하는 구조로 바꾸고, open()이나 isLandMineCell()과 같이 '지뢰찾기'에 의존적인 역할은 "MineSweeperGameBoard 같은 자식에서 구현해야 하나?" 하는 생각이 들게 되어서요!
좀 두서없는 질문이고 엉뚱할 수 있지만 공유자님이라면 게임의 종류가 다양해진다면 어떤 고민을 시작으로 변경해 나가시는지, 어떤 부분을 먼저 생각해보는 것이 좋을지 궁금합니다.(사고의 흐름..?)
좋은 강의 감사드리며, 앞으로도 더 좋은 강의 부탁드리겠습니다!
감사합니다 😃
답변 2
0
안녕하세요, wjdghks5698 님!
좋은 질문이네요. 요구사항에 따라 구현 방향이 달라지겠지만, 아마 하나의 GameBoard 구현체를 두고 여러 게임이 공유한다면 기능을 정말 잘 세분화해야 할 것 같아요.
보드판 자체가 그저 판을 생성하고, 기물을 표시하는 정도의 역할을 갖는다면 대부분의 보드판 게임에서 필요한 기능이니 말씀하신대로 가능할 것 같아요.
조금이라도 각 게임에 특화된 기능이 보드판에 필요한 상황이라면, 오히려 게임 별로 보드판을 두는 게 향후 유지보수에 편할 수도 있습니다. (보드의 기능을 중복해서 만드는 불편함이 있겠지만요)
지금 가볍게 생각하기에는 공통의 보드판을 사용하는 게 가능할 것 같네요. 주어진 요구사항을 중심으로, 그리고 미래에 발전 가능성이 높은 방향으로 의사결정하고 프로덕트를 설계하시면 됩니다. 보드처럼 여러 곳에서 활용되는 기능이 잘 분리되어 재사용되고 확장되는 것을 목표로 해보면 좋을 것 같네요.
감사합니다. 🙂
0
안녕하세요, 인프런 AI 인턴입니다. wjdghks5698님!
먼저 이렇게 좋은 질문을 주셔서 감사합니다. 다양한 게임에 대응하는 시스템을 설계하는 것은 매우 흥미로운 도전입니다. 객체지향 설계에서 중요한 부분이며, SRP(단일 책임 원칙)를 확장하여 응집도 높은 설계를 만드는 것이 초점이 되겠네요.
게임 종류 확장에 따른 설계 고민
GameBoard의 추상화:
- 게임의 공통적인 요소를 추출하여
GameBoard를 추상화해야 합니다. 이 클래스는 게임판의 공통적인 속성과 동작을 정의합니다.
- 다른 게임(예: 체스, 오목)은 이러한 공통 기능을 기반으로
GameBoard를 상속받아 구현합니다.
- 게임의 공통적인 요소를 추출하여
게임별 특화된 기능:
MineSweeperGameBoard,ChessBoard,GoBoard등 각 게임에 특화된 기능은 구체적인 자식 클래스에서 구현합니다.
- SRP 원칙에 따라 게임별 특화된 기능을 명확히 분리하고, 필요한 메서드(예:
isLandMineCell())는 해당 메서드를 필요로 하는 게임 클래스에서 정의하도록 합니다.
인터페이스 도입:
- 만약 여러 종류의 게임의 기능이 크게 다르다면, 공통 인터페이스를 마련할 수 있습니다. 예를 들어,
Playable인터페이스를 통해 모든 게임이 채택해야 하는 공통 메서드(예:play(),end())를 정의할 수 있습니다.
- 만약 여러 종류의 게임의 기능이 크게 다르다면, 공통 인터페이스를 마련할 수 있습니다. 예를 들어,
디자인 패턴 활용:
- 전략 패턴이나 템플릿 메서드 패턴과 같은 디자인 패턴을 통해 서로 다른 행동을 구현할 수 있습니다. 이를 통해 구체적인 게임 규칙을 각 클래스에 캡슐화할 수 있습니다.
- 전략 패턴이나 템플릿 메서드 패턴과 같은 디자인 패턴을 통해 서로 다른 행동을 구현할 수 있습니다. 이를 통해 구체적인 게임 규칙을 각 클래스에 캡슐화할 수 있습니다.
확장성을 고려한 설계:
- 새로운 게임을 추가할 때마다 최소한의 변경으로 시스템이 동작할 수 있도록 개방-폐쇄 원칙(OCP)를 충족시키는 것이 관건입니다.
- 새로운 게임을 추가할 때마다 최소한의 변경으로 시스템이 동작할 수 있도록 개방-폐쇄 원칙(OCP)를 충족시키는 것이 관건입니다.
참고할 질문과 답변
아래의 링크에서 비슷한 주제에 대한 토론을 살펴보시면 더 많은 인사이트를 얻으실 수 있습니다:
이 과정은 초기 단계부터 다양한 게임을 염두에 두고 설계하는 것보다는, 필요에 따라 점진적으로 구조를 확장하고 리팩토링하는 것이 좋습니다. 설계는 항상 유연성과 단순성 간의 균형을 맞추는 것이 중요합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.