wbluke

안녕하세요, 인생은회전목마 님!맞습니다. 하위 객체의 구현 내용이 변경되는 것은 어차피 상위 객체에서 알 수 없기 때문에 그것을 이야기하는 것은 아니고요. 상위 객체가 하위 객체를 직접 참조하게 되면, 일단 해당 하위 객체의 이름부터, 패키지(참조 위치), 말씀하신 메서드 시그니처까지 모든 정보를 다 알고 있게 됩니다. 구현체도 하나로 고정되기 때문에, 요구사항에 변경이 생겨 A 구현체가 B 구현체로 변경되어야 하면 A 구현체를 직접 의존하고 있는 모든 상위 객체가 변경이 필요해집니다. 만약 100군데라면 100개의 파일에 변경이 일어나겠죠. 하지만 이미 잘 아시는 것처럼 인터페이스를 활용해 의존 방향을 역전시키면, 상위 객체는 구현체의 기능(스펙)만 알지 실제로 어떤 구현체가 연결되는지는 알 수 없습니다. 애초에 관심을 가질 필요도 없는 것이고요.도움이 되셨기를 바랍니다. 감사합니다. 🙂&nbsp;

DIP 개념에 대한 질문입니다.

안녕하세요, wjdghks5698 님!좋은 질문이네요. 요구사항에 따라 구현 방향이 달라지겠지만, 아마 하나의 GameBoard 구현체를 두고 여러 게임이 공유한다면 기능을 정말 잘 세분화해야 할 것 같아요.<ul><li>보드판 자체가 그저 판을 생성하고, 기물을 표시하는 정도의 역할을 갖는다면 대부분의 보드판 게임에서 필요한 기능이니 말씀하신대로 가능할 것 같아요.</li><li>조금이라도 각 게임에 특화된 기능이 보드판에 필요한 상황이라면, 오히려 게임 별로 보드판을 두는 게 향후 유지보수에 편할 수도 있습니다. (보드의 기능을 중복해서 만드는 불편함이 있겠지만요)</li></ul>지금 가볍게 생각하기에는 공통의 보드판을 사용하는 게 가능할 것 같네요. 주어진 요구사항을 중심으로, 그리고 미래에 발전 가능성이 높은 방향으로 의사결정하고 프로덕트를 설계하시면 됩니다. 보드처럼 여러 곳에서 활용되는 기능이 잘 분리되어 재사용되고 확장되는 것을 목표로 해보면 좋을 것 같네요.감사합니다. 🙂

만약 보드를 이용한 게임의 종류가 더 다양해진다면 어떻게 될 수 있을지에 대한 고민

안녕하세요, 인생은회전목마 님!먼저 컴파일 타임과 런타임 시점을 구분해서 이해하셔야 합니다. DIP가 적용되지 않은 코드는 인터페이스 없이 상위 모듈이 하위 모듈을 직접적으로 참조하고 있게 됩니다. 컴파일 타임부터 어떤 객체를 참조할지 알고 있게 되는 것이죠. DIP가 잘 적용되어 인터페이스로 참조할 구현체의 기능만 알고 있고, 직접적인 구현체 자체는 알 수 없는 구조라면, 컴파일 시점에는 알 수 없지만 실제 실행 시점인 런타임 시점에 구현체를 주입받게 됩니다.<blockquote>스프링 IOC의 장점을 설명하라고 하면 제어의 역전이 되면서 구현 인스턴스 변경에 유연해진다라고 들었는데</blockquote>위와 같이 표현하신 것처럼 직접 참조가 아닌 인터페이스를 통한 참조라면 하위 모듈인 구현체 객체가 변경되어도 (인터페이스 스펙만 유지한다면) 상위 모듈이 영향을 받지 않습니다. 그렇기에 "변경"에 유연해진다고 하는 것입니다. 구현체가 꼭 하나만 있는 상황 말고도, 스프링에서는 런타임 시점에 여러 구현체(Bean) 중 상황에 맞는 것을 선택하여 주입할 수도 있습니다. 이처럼 동일한 인터페이스 스펙만 유지된다면 구현체를 얼마든지 교체할 수 있기 때문에, 스프링 IoC는 변경에 유연한 구조라고 할 수 있습니다.도움이 되셨기를 바랍니다.감사합니다. 🙂&nbsp;

DIP 설명 후반부에 IOC에 대한 질문 드립니다.

안녕하세요, 박시콩 님!네, 그럼요! 충분히 가능합니다. 특정 언어의 고급 기능을 사용하는 예제가 아니라서, 모르는 문법이 나와도 그때마다 가볍게 학습하면서 진행하시면 충분히 따라가실 수 있습니다. (요즘은 또 GPT가 잘 알려주니까요~)감사합니다 🙂

안녕하세요 ! 혹시 자바가 아닌 다른 객체지향 언어를 알고있어도 강의를 들어도 괜찮을까요 ?!

안녕하세요, III 님!어느 방법이 무조건 더 좋다고 말하기는 어려운데요, 상황에 따라 선택하시면 될 것 같아요.Tip 이라는 도메인의 특성이 항상 save 행위을 기반으로 동작해야 한다면 1번이 더 편할 것이고, 그렇지 않고 저장이 아닌 다른 행위만 수행하는 경우도 있다면 2번을 고려해볼 수도 있을 것 같네요.Builder의 경우는 객체 생성에 관련된 코드이니, 저는 객체(여기서는 Entity) 안에 넣고 있습니다.도움이 되셨기를 바랍니다. 감사합니다. 🙂

안녕하세요 메서드명 때문에 고민이 있어서 질문드립니다.

안녕하세요, seonrizee 님!저는 다음과 같이 생각합니다.<ul><li>커버리지 자체를 중요하게 신경쓰는 것 보다는 중요도에 따른 도메인/비즈니스 로직에 집중하여 테스트 코드를 작성하는 것이 맞다.</li><li>다만, 팀 내에서 커버리지 자체에 대한 최소 기준을 가져가는 것은 팀원 모두가 의식적으로 테스트 코드를 꾸준히 작성하게끔 하는 동력이 될 수 있다.<ul><li>ex. 우리 팀의 최소 라인 커버리지는 60%로 정한다. (향후 커버리지가 더 좋아지면, 65, 70% 로 높여서 적용해나갈 수도 있음)</li></ul></li></ul>감사합니다. 🙂

커버리지는 어떻게 활용하시는지 궁금합니다.

안녕하세요, save 님!테스트 코드 자체를 굳이 문서화하지는 않습니다. 이미 테스트 코드 자체가 문서의 기능을 하고 있기 때문입니다. ㅎㅎ도움이 되셨기를 바랍니다. 감사합니다. 🙂

테스트 문서화 질문입니다

안녕하세요, woo93xna 님!상황에 따라 다른데요. 예를 들어 만약 native query로 직접 구현한 CRUD 기능이라면 당연히 내가 작성한 기능이니 테스트가 필요할 것이고요.JpaRepository 같이 이미 라이브러리 단에서 보장된 기능은 (물론 테스트 해도 되지만) 굳이 테스트하지 않으셔도 괜찮습니다. 우리에게 중요한 것은 시간이고, 그 시간에 상대적으로 더 중요한 테스트에 힘을 쏟는 것이 이득이기 때문입니다.도움이 되셨기를 바랍니다. 감사합니다. 🙂

단위테스트 질문이 있습니다

안녕하세요, jaljayo85 님!Controller 계층은 보시다시피 매우 얇은 계층으로, 비즈니스 로직이 없고, 파라미터의 검증 정도만을 담당하고 있습니다. 따라서 Controller를 테스트하고자 할 때는 상대적으로 무거운 비즈니스 로직을 담고 있는 Service를 mocking하는 것이 적절한 판단이라고 생각합니다.반면 Service, Repository 는 두 레이어가 연합하여 비즈니스 로직을 전개하고 있으므로, (Repository의 기능도 단독 테스트로 보장함과 동시에) 통합 테스트를 작성하여 원하는 요구사항을 반영하고 있는지를 테스트한다고 이해해주시면 되겠습니다.도움이 되셨기를 바랍니다. 감사합니다. 🙂

컨트롤러는 모킹을 한 이유가 궁금합니다.

안녕하세요, 김혁준 님!네, 맞습니다. 엮여 있는 도메인이 많을수록 벌어질 수밖에 없는 상황이기에, 아래와 같은 방법을 사용해보시면 좋습니다.<ul><li>테스트 클래스 내에서 중복 로직 추출&nbsp;</li><li>(적절한 관리가 가능하다면) fixture 를 쉽게 만들 수 있는 유틸 클래스 추가 및 이용</li></ul>예를 들어 C 도메인을 만들기 위해 A, B 도메인이 순차적으로 필요한 상황에서, 대부분의 테스트에서 A, B가 크게 달라지지 않는다면 위와 같은 방법을 사용해 생산성을 높여볼 수 있을 것 같아요.다만, 너무 많은 정보를 함축하여 테스트 코드를 읽을 때 어려움이 생기는 상황은 잘 피해서 도입하는 것이 좋겠습니다.도움이 되셨기를 바랍니다. 감사합니다. 🙂

wbluke

投稿