Spring Framework의 시작

현재까지는 스프링부트를 이용해 구글링을 하며 웹 MVC구조로 정말 간단하게 동작되는 웹서버를 구현해서 DB와도 연동해보았다.

물론 원리들을 이해하고 만들어본 게 아니라 책과 검색을 통해서 무작정 따라만들었다. 동작은 하지만 왜 이렇게 되고 어노테이션들에 대해서도 궁금했고 그래서 원리를 제대로 공부해보자 생각하였고, 기초부터 제대로 공부를 하며, 무작정 보며 따라치는 과정에서 벗어나 원리를 하나씩 이해하는 시간을 가져보았고 이를 정리하고자 블로그에 글을 게시하기로 마음 먹었다.

 

나에게 있어서 객체지향의 개념이 단순히 객체지향언어인 자바 문법을 공부한다고 쉽게 얻어지는 게 아니었다. 자바 문법을 공부했음에도 객체지향에 대해서 이해를 하지 못했다. 그냥 클래스가 틀이고 쿠키를 만드는 거처럼 찍어내서 코드의 재사용이니 마니.. 암기식으로 이해를 하고 있어서 객체지향의 사실과 오해란 책을 구매해 읽기도 하였다. 객체지향설계의 개념인 SOLID도 접해보지 못했던 개념이고 공부가 필요했다. 왜 학교에선 이렇게 중요한 개념들을 안가르쳐주는지 의문도 든다. 혼자서 공부를 한 결과 내가 어렴풋이 OOP란 이런 것일거야라고 예상했던 것들이 다 틀렸단 걸 알 수 있었다.

 

SOLID란 SRP, OCP, LSP, ISP, DIP라는 다섯가지의 중요한 원칙을 뜻한다.

다섯가지의 개념 중에서도 중요하고 흥미로운 개념은 SRP, OCP ,DIP 이 세가지였다.

SRP는 single responsibility principle 말 그대로 단일 책임 원칙으로 한 객체는 하나의 책임만 부여하여야 된다는 것이다.

객체지향적으로 개발한다는 것이 객체들끼리 메시지를 주고 받고 레고 부품을 갈아끼우듯 유연한 개발을 뜻하는 것이므로 한가지의 레고 부품에 너무 많은 책임을 부여한다면 그것은 유연한 개발을 방해하는 요소가 된다는 것이다. 그래서 단순히 클래스라는 문법을 배우고 아무렇게나 클래스를 만들며 그 클래스 안에 여러개의 필드와 메서드를 만들었던 내 자신이 창피하였다.

 

그리고 두번째 개념은 OCP이다. OCP란 open/closed principle 개방 폐쇄 원칙으로 처음 볼 땐 이게 무슨 말인가 싶었다.

OCP는 확장에는 열려있고, 변경에는 닫혀있어야 한다는 뜻이다. 애플리케이션을 개발하다가 기능을 확장하는 일이 생긴다면 확장에는 열려있어야 하며 클라이언트 코드는 변경이 없어야한다. 예를 들어 Service 클래스가 있다고 가정하고 Serivce 클래스가 DB에 접근하는 JdbcRepository라는 클래스를 의존하고 있었다. 하지만 어떠한 문제로 인해 DB를 변경해야한다면 기존에 Service 클래스에서 의존하는 코드를 수정하는 것은 불가피하다. 그래서 이를 해결하려면 우선 인터페이스로 Repository클래스를 만들고 구현클래스는 따로 작성하여야 한다. 처음엔 이렇게하면 OCP가 지켜지는 줄 알았다. 하지만 인터페이스 안에서 new를 써서 구현객체를 적어줘야하는데 결국엔 클라이언트의 코드 변경은 불가피한 상황이다. 나의 시야가 좁다고 느껴진 게 이 부분이었다. 두 클래스 안에서 문제를 해결해야 한다는 관점을 벗어나 또 다른 설정자로 이 둘의 의존관계를 설정해주면 해결되는 일이었다. 별도의 설정을 하는 클래스를 만들고 그 안에서 서로의 의존 관계를 주입하는 것이다. 그러면 클라이언트의 코드를 수정할 일은 없어지고 OCP를 위반하는 일도 없어진다.

 

DIP는 dipendency inversion principle 의존관계 역전 원칙으로 프로그래머는 추상화에 의존해야하며, 구체화에 의존하면 안된다는 뜻이다. 위의 OCP설명에서 나와있는 내용과 겹치는 부분이다. A클래스가 B클래스를 의존하고 있다면 A클래스는 B클래스의 인터페이스만을 의존해야하며 인터페이스의 구현클래스는 의존하면 안된다는 것이다. 이 문제는 별도의 설정자인 Config클래스로 해결할 수 있으며, 그로 인해 OCP도 지켜지고 DIP도 지켜지고 한 클래스에서 구현객체를 불러오는 책임에서 벗어나니 자연스레 SRP도 지켜지게 되었다.

 

 

객체지향설계에 대해서 검색을 하면 설명으로 봤던 글 중에 하나가 객체들간의 강한 결합은 유연한 개발을 방해한다, 객체들간의 결합을 느슨하게 해줘야된다라는 말을 본 적이 있는데 당시엔 이게 무슨 말인지 도무지 알 수가 없었다. 하지만 SOLID 원칙에 대해서 알게되고 비로소 이 말의 뜻일 이해할 수 있게 되었다.

 

클라이언트 코드에서 구현체를 직접 의존하게 되면 큰 프로젝트일수록 변경에 유연하지 못하고 수정해야할 코드도 많아지며, 어떤 문제가 일어날지 예측하기 어려워진다. 그래서 SOLID라는 원칙이 있고, 그리고 그 원칙을 잘 지킬 수 있게 도와주는 게 스프링 프레임워크의 역할이다. 다음 시간엔 스프링 프레임워크가 어떻게 의존관계를 주입하는지에 대해서 공부한 내용들을 정리해보겠다.