⛅️[구름톤 트레이닝 풀스택 6회차] - 9주 차 회고⛅️

저의 회고 방식은 5F 입니다

사실, 무슨 일이 있었나요?

김영한 님의 스프링 MVC 1, 2편을 수강하였습니다.

api 응답 구현 PBL을 진행하였습니다.

PBL을 진행하며 느낀 의문사항들이 있었습니다.

 

느낀점, 어떤 느낌이 들었나요 ?

저번 주차에 자바에서 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경됨으로써 OCP, DIP를 지킬 수 없어서 뭔가 더 필요한 것을 이번 주차에 적겠다고 했습니다.

 

2024.02.24 - [구름톤 트레이닝 풀스택 회고] - ⛅️[구름톤 트레이닝 풀스택 6회차] - 8주 차 회고⛅️

⛅️[구름톤 트레이닝 풀스택 6회차] - 8주 차 회고⛅️

 

 

제어의 역전(IOC), 의존관계 주입(DI)

 

 

순수 자바 코드만으로는, 인터페이스에만 의존하는 것이 아닙니다.

사실은 인터페이스, 구현체 클래스 둘 다 의존하는 것이었습니다.

public class userServiceImpl implement userService {
	private final UserRepository userRepository = new UserRepositoryImpl()   
}

위에 코드는 역할과 구현을 확실히 나눈 것처럼 보이지만 사실은 인터페이스와 구현체 둘 다 의존을 하고 있는 것입니다.

 

따라서 해결 방안으로는 인터페이스에만 의존해 줘야 하는데, 이러한 해결법은 구현 객체를 누군가 대신 생성하고 주입해 주어야 합니다.

 

이러한 역할을 대신해주는 것이 스프링 컨테이너인데, 스프링부트에서는 

@Component, @Repository, @Controller 등의 어노테이션을 자동으로 인식하여 스프링 컨테이너에 빈으로 등록해 줍니다.

@RequiredArgsConstructor
public class UserServiceImpl implements UserService {
    private final UserRepository userRepository;
}

 

스프링 컨테이너에서는 구현체인 userResporitoryImpl를 자동으로 찾아서 UserServiceImpl에 주입해 줍니다.

이렇게 스프링 컨테이너를 사용함으로써, 개발자는 인터페이스에만 의존하면서도 구현체의 생성과 연결은 스프링 컨테이너가 자동으로 처리해 주므로, 역할과 구현의 분리 원칙을 잘 지킬 수 있었습니다.

 

 

정리하면 제어의 역전(IOC)는 말 그대로 제어의 역전입니다.

개발자가 객체를 생성을 관리하며 제어하는 게 아닌, 스프링 컨테이너에게 제어권을 넘겨 스프링 컨테이너가 흐름을 제어하는 것입니다.

 

DI는 의존성 주입입니다.

객체를 직접 개발자가 생성하는 것이 아니라, 외부 (IOC 컨테이너)에서 생성한 이후 주입시켜주는 방식입니다.

 

대학 시절 스프링 부트만을 사용하며 이러한 내부 동작 방식을 잘 이해하지 못했지만, 구름톤을 통해 스프링을 공부해 보며 좀 더 탄탄한 지식을 쌓을 수 있었습니다.

 

배운 점, 어떤 인사이트를 얻었나요 ?

구름톤에서는 다양한 주제로 멘토링을 받을 수 있는 기회인 오피스아워가 존재합니다.

저는 PBL을 진행하여 있었던 의문점을 해결하기 위하여 오피스아워를 신청했습니다.

 

그중 제일 큰 의문점이었던 것은 요구사항에 따라 OCP 원칙을 지키기 위해서 서비스와 레포지토리를 인터페이스와 구현체로 나눠 확장할 가능성을 열어둔 상황입니다.

 

구현을 하다보니, 해당 과제의 경우 확장 가능성이 없다고 판단했습니다.
이러한 경우에도 확장할 가능성을 열어두고 개발하는 것이 좋을까?

 

모든 기능에 있어서 확장 가능성을 열어두고 개발해야 할까? 언제 확장 가능성을 열어두고 개발을 하는것이 좋을까?

 

멘토님의 답변은 결국 둘다 고쳐야 하는 상황이 발생하기 때문에 구현체 클래스가 하나일 경우는 안 하시고, 필요한 순간에 나누신다고 하셨습니다. 그 이유는 처음에 계획하는 게 나중에는 달라지는 경우가 많았다고 하셨습니다.

그리고, 이러한 주제는 현업에서도 정말 자주 다루는 문제이고 면접 때 충분히 나올 수 있는 질문이므로, 정답이 없으니 자신의 생각을 정리해 주는 것이 좋다고 하셨습니다.

향후 행동 앞으로 무엇을 해야 할까요 ?

 

자바를 확실히 이해하고, 스프링을 진행하니 더 깊은 이해를 할 수 있었던 것 같습니다.

김영한 님 께서는 왜 옛날 코드인 레거시를 먼저 알려주는 방식을 선호하시는지 깨닫게 되었습니다.

현재는 스프링부트, 스프링 스타트 JPA와 같은 편리한 기술을 사용하지만, 옛날에 쓰이던 코드를 먼저 이해하지 못하고 사용하면 내부동작 방식을 절때 이해하지 못하고 사용한다는 것을 깨닫게 되었습니다.

이러한 접근방법을 알았으니 다음 강의 DB에 관하여서도 내부동작 방식을 확실히 이해해야 될 것 같습니다

 

 

출처 

김영한 님의 스프링 MVC 1편

김영한 님의 스프링 MVC 2편