1-5. 객체 지향 설계와 스프링

그래서 스프링과 객체 지향이 무슨 상관이 있는지 간단히 설명해주는 회차이다.

 

 

스프링 강의에 왜 객체 지향 이야기가 나오는가?

다형성에다가 OCP와 DIP까지 모두 가능하게 만들어주는 것이 스프링이기 때문이다.

DI(의존성 주입), DI 컨테이너 제공 등의 기술을 통해 그렇게 한다.

 

덕분에 클라이언트 코드를 변경하지 않고 기능을 확장할 수 있으며,

부품을 교체하듯이 쉽게 개발할 수 있다.

 

 

 

어떤 불편함 때문에 스프링을 만들었는가?

스프링이라는 놈을 만들지 않더라도, 자바 코드를 아주 잘 짜서 스프링이 제공하는 그런 기술들을 직접 구현하면 OCP와 DIP를 준수할 수 있다.

 

그러나!

그러려면 할 것이 너무 많아진다.

개발을 좀더 편하고 깔끔하게 하려는 것 뿐인데, 이를 위해 본래의 핵심 코드보다 더 많은 양의 작업을 해야 한다. 배보다 배꼽이 더 커진다.

 

따라서 그런 부분들을 미리 프레임워크로 만들어놓고

그때그때 직접 순수 자바로 만들 필요 없이 가져다 쓰는 게 낫다.

 

어차피

스프링 없이 순수 자바 코드만으로 OCP와 DIP를 준수하는 프로그래밍 구조를 만들어보면

결국은 스프링과 유사한 DI 컨테이너를 만들 수밖에 없다.

 

 

 

정리

모든 설계에서 역할과 구현을 분리하자.

 

무슨 역할들이 필요한지에 대한 설계도는 미리 그려놓되,

그 역할에 정확히 어떤 놈이 배정될지는 언제는 바꿀 수 있도록 하는 것이다.

 

즉 모든 설계에 인터페이스를 부여하는 게 이상적이라고 볼 수 있는데...

 

 

 

 

실무 관점에서 고민해볼 점

강사님 말씀에 따르면 사실 안 그런 경우도 있다.

 

나중에 다른 구현체로 갈아끼울 일이 없어보인다면,

처음부터 그냥 인터페이스 없이 구현체로 짜버리는 게 나을 수 있다고 한다.

 

그랬는데 예상과 달리 구현체를 바꿀 필요가 생긴다면?

그때 가서 리팩터링을 통해 인터페이스를 뽑아내주어도 된다.

 

그리고 죄다 인터페이스로 만들어놓는 게 안 좋은 경우도 있다.

구체적인 구현체로 짠 프로그램은 코드를 까서 딱 보면 한 눈에 모든 구체적인 내용을 파악할 수 있다.

그런데 인터페이스로 추상화시켜놓으면

코드를 열어봤을 때 인터페이스들만 먼저 보인다.

코드를 타고 타고 들어가서 구현체들까지 넓게 살펴봐야 전체적인 내용을 파악할 수 있다.

 

어떤 방식으로 개발해야 현재 상황에서 가장 효율적일지 잘 판단하는 사람이 노련하고 능력 있는 개발자라고 한다.

 

 

 

 

 

다음 강의부터는 실제 코드를 짜보며 공부한다.