player 내부에 worldmap

김철준님 안녕하세요.Player 내부에 WorldMap이 위치하는게 어색한 이유와 Game 안에 포함되는게 더 낫다고 생각하시는 이유를 적어 주시면 좀 더 정확한 답변을 드릴 수 있을 것 같습니다.더 자세한 답변은 위 내용을 적어주시면 드리기로 하고 우선 대략적으로 답변드릴게요. 어떤 구조를 선택할 것인지는 응집도나 결합도와 같은 측면을 트레이드오프해서 그 중에서 합리적인 안을 선택해야 합니다.말씀하신 안이 아래 그림의 (A)인지 (B)인지 정확하게 몰라서 둘 모두를 기준으로 답변드릴게요.(사진)현재의 텍스트 어드벤처 게임은 Player를 기준으로 특정한 액션을 수행하고 있습니다.(A)안이 구조로 설계하면 Game이 Player와 WorldMap을 조율해서 Player의 동작을 처리해야 합니다. 따라서 Game에 Player를 처리하는 로직이 위치하게 되어 응집도가 낮아지게 됩니다. 추가로 Game이 WorldMap과 Player 모두를 알아야 하기 때문에 Game의 결합도가 높아지게 됩니다.(B)안이 구조로 설계하면 Player를 처리하기 위해 WorldMap을 거쳐야 합니다. 따라서 Player만 필요한 로직의 경우에도 WorldMap에 Player로의 위임 로직을 추가해야 합니다.따라서 WorldMap의 응집도가 낮아지게 됩니다.또한 Player는 처리를 위해 WorldMap의 정보가 필요하기 때문에 양방향 연관 관계가 추가하거나 WorldMap의 데이터를 전달해야 하기 때문에 결합도가 높아지거나 코드가 복잡해지게 됩니다. 위 이유로 Player가 WorldMap을 참조하도록 구성했습니다.제가 드린 답변이 생각하신 이슈와 상관이 없다면 어색하다고 느끼신 이유와 Game에 포함시켰을 때 더 개선된다고 생각하시는 부분을 남겨 주시면 더 자세히 답변 드릴게요.

7-3 AbstractReader에 대해

반대로 XML리더나 HTML 리더를 만들때도 공통 코드가 달라진다고 보장할 수도 없습니다.이 시점까지 구현해야 한다고 알고 있는 JsonReader와 CsvReader는 모두 로컬 파일시스템에서 파일을 읽는 로직을 공유합니다.따라서 실제로 필요한 변경이 일어날 때까지는 현재 알고 있는 내용 안에서 구현하면 되는거죠.상위 모듈은 하위 모듈에 비해 상대적으로 안정적인 부분입니다.다시 말해서 변경할 수 없는 코드가 아니라 하위 모듈보다 상대적으로 더 적게 변경하는 부분입니다.원격에서 읽는 부분에 대해서 문의 주셨는데 강의를 보시면 아시겠지만 원격이라는 요구사항이 추가되는 순간 현재이 구조는 리팩터링하게 됩니다.현재 상황에서 추상 클래스가 상위 모듈 안에 위치하는게 중복 코드나 의존성 관리 측면에서 유리한 것이기 때문에 현재 구조는 유효합니다.

9-6 순환참조인거 같은데..

Game을 수정했을 때 Gui, Cui로 변경되는 문제는 양방향 참조와는 무관합니다.단순히 Gui와 Cui가 각각 Game에 의존하고 있기 때문에 Game 수정 시에 영향을 받는 것뿐입니다.Game과 Gui, Cui가 양방향 참조라면 Game 클래스 안에 Gui와 Cui 인스턴스를 참조로 포함해야 합니다.마찬가지로 순환참조도 아닙니다.순환참조는 자기 자신에서 시작해서 의존성 그래프를 따라갔을 때 자기 자신으로 돌아와야 합니다.그림에서 보시면 모든 의존성은 GameLoop에서 끊깁니다.

8-5 오타

화면의 자막은 인프런에서 자동으로 강제 생성해주는 것으로 지식관리자에게 수정 권한이 없고 수강생과 동일하게 수정 제안만 할 수 있습니다.AI의 자막 기능이 완벽하지는 않아 불편을 드렸네요.일단 수정 제안해 두었으며 인프런 제공 자막의 품질이 떨어지면 제가 자막을 제공하는게 더 낫겠네요.

7-3 모듈의존성 역전에 대해

예제의 CallCollector처럼 Reader와 같이 인프라를 추상화한 인터페이스를 이용해서 의존성을 역전 시키는 방법은 애플리케이션 레이어에서 매우 빈번하게 사용됩니다.도메인 레이어에서도 도메인 서비스 내부에서 외부 인프라에 의존할 경우에는 의존성 역전 원칙을 이용해서 구현과 인터페이스를 분리하는 방법을 자주 사용합니다.그 외에도 의존성 순환을 제거하거나, 테스트 용이성을 향상시키거나, 재사용성을 높이거나, 유연성을 향상시키기 위해서도 의존성 역전을 자주 사용합니다.

7-5 자막오타

화면의 자막은 인프런에서 자동으로 강제 생성해주는 것으로 지식관리자에게 수정 권한이 없고 수강생과 동일하게 수정 제안만 할 수 있습니다.현재 강의에서 제가 만든 자막은 제공되지 않습니다.일단 수정 제안해 두겠습니다.

7-5 자막오타

화면의 자막은 인프런에서 자동으로 강제 생성해주는 것으로 지식관리자에게 수정 권한이 없고 수강생과 동일하게 수정 제안만 할 수 있습니다.현재 강의에서 제가 만든 자막은 제공되지 않습니다.일단 수정 제안해 두겠습니다.

7-3 자막오타

화면의 자막은 인프런에서 자동으로 강제 생성해주는 것으로 지식관리자에게 수정 권한이 없고 수강생과 동일하게 수정 제안만 할 수 있습니다.현재 강의에서 제가 만든 자막은 제공되지 않습니다.일단 수정 제안해 두겠습니다.

책 두권 다 읽어봐야 할까요?

김철준님 안녕하세요.오브젝트 - 기초편은 오브젝트 책과는 다른 관점에서 접근하고 있습니다.예제는 동일하지만 책임 주도 설계의 다양한 배경을 추가로 다루고 있으며, 책에서는 간단하게 언급만하고 넘어간 응집도, 결합도, 캡슐화의 개념을 심도 깊게 다루고 있습니다.기본적인 개념부터 시작해서 코드 레벨까지 단계적으로 설명하고 있기 때문에 책을 보지 않고 강의를 보시는 것만으로도 충분히 개념을 이해하실 수 있으실 거에요. 🙂혹시 보시다가 궁금한 내용 있으시면 언제라도 질문 남겨주세요!

(질문 글) Movie와 Customer의 위치

김태호님 안녕하세요.좋은 질문 남겨 주셔서 감사합니다. 🙂아래에 답변 드릴게요. 메서드 인자로 Movie 전달메서드 인자로 Movie를 전달받는 경우에는 메서드를 호출하는 클라이언트쪽에서 Movie를 조회해서 전달해줘야 합니다.만약 Screening 클래스 안에서 Movie를 인자로 전달받는 메서드가 많아진다면 Screening을 사용하는 클라이언트에서 맡아야 하는 책임이 늘어나겠죠.Screening의 메서드를 호출하는 모든 클라이언트에 조회 로직을 추가해야하기 때문에 Screening 클래스의 사용성이 저하되게 됩니다.Screening이 Movie와 빈번하게 협력해야 한다면 Screening이 Movie의 참조를 포함하도록 결합도를 높여서 Screening과 Movie 객체 그룹의 사용성을 높일 수 있을 겁니다.반면에 Screening의 메서드에서 Movie에 메시지를 전송하는 경우가 빈번하지 않고 결합도를 낮추는게 사용성 관점에서 더 중요하다면 말씀하신 것처럼 Movie를 인자로 전달하는 방법을 선택할 수 있습니다.이 경우에는 어떤 참조는 끊고 어떤 참조는 연결할 지에 대한 고민이 필요합니다. 메서드 인자로 id 전달메서드 인자로 id를 전달하면 Screening에서 Movie를 조회해야 합니다.이를 위해 Screening에 Movie를 조회하는 책임을 담당하는 객체를 의존성 주입하거나 서비스 로케이터 형태로 객체를 조회해야 합니다.이 경우 Screening이 조회를 위한 객체에 불필요하게 의존하게 되어 결합도가 높아지고, 결과적으로 단위 테스트 작성이 어려워지게 됩니다.따라서 가급적이면 도메인 로직을 처리하는 클래스에서 조회 로직을 분리하시는게 좋습니다. 예제의 경우처럼 Screening이 Movie를 꼭 참조로 연결할 필요는 없지만 응집도와 결합도 측면에서 트레이드오프를 하시는게 좋습니다.답변이 되었는지 모르겠네요. 🙂감사합니다.