이전에 작성했던 글을 복습할겸 보다가 의존 관계 주입에서 우테코 과제 코드가 생각나면서 멈칫했다. 의존 관계 주입은 애플리케이션 실행 시점에 외부에서 구현 객체를 생성해서 의존 관계가 연결되는 것으로 결합도를 낮추고 유연성을 확보할 수 있다.
[Spring] 스프링 핵심 개념 (1/2)
스프링의 핵심 원리는 다형성과 SOLID 원칙을 따르는 설계 SOLID 5 원칙 로버트 마틴이 정의한 객체 지향 프로그래밍 설계의 기본 원칙 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적
treecode.tistory.com
우테코 과제에서 테스트 코드를 작성하기 어려웠던 부분이 있는데 BridgeMaker를 필드에서 초기화하면서 BridgeRandomNumberGenerator()를 생성하는 부분이였다. BridgeNumberGenerator의 구현체인 BridgeRandomNumberGenerator는 1과 0의 랜덤한 숫자를 생성해주는 역할을 한다.
BridgeGame을 테스트 할 때 랜덤하게 생성되는 숫자 때문에 테스트를 해보기가 까다로웠는데 이는 필드에서 BridgeRandomNumberGenerator를 생성하기 때문에 결합도가 높고 유연성이 떨어지기 때문이였다.
BridgeMaker를 생성자를 통해 전달을 받으면 BridgeMaker를 외부에서 생성할 수 있고 테스트를 할 때 BridgeNumberGenerator의 테스트 구현체를 별도로 생성하면 된다.
추가로 BridgeMaker는 처음에 한번 다리를 생성하는 역할만 하기 때문에 BridgeGame의 필드로 선언할 필요가 없는 것 같다.
지금 와서 다시 보니 코드를 작성하면서 SOLID 원칙을 잘 지키고 있는지 고민이 부족했던 것 같고 Lombok의 @RequiredArgsConstructor 애노테이션을 쓰면서 직접 생성자 코드를 안 만들다보니 아무 생각 없이 필드에 생성한 것 같다. (반성 ㅠ)