스프링 핵심 원리 - 기본편 섹션 2를 듣고

API 사용법을 안다고, 잘 만든다고 해서 스프링을 잘하는 게 아니다.

이 기술을 왜 만들었는지. 개발자가 스프링을 개발하면서 담고 싶었던 컨셉은 무엇인지.

핵심 컨셉에 대해서 제대로 이해하고 사용을 해야 ’내 것’이 된다.

김영한님이 하신 말씀을 듣고 뒷통수가 얼얼했다 ;;

지금까지는 스프링이 뭔지, 어떤 컨셉을 가지고 만들어졌는지에 대해서 알려고도 한 적도 없이

그냥 요구사항들이 있으니까 그에 맞게 API를 만들었고, 코드 가독성이나 효율에 더 힘을 썼다.

이제부터라도 스프링의 본질을 알아가고 싶고, 그 과정을 기록하고 싶기에 글을 작성하겠다.

자바는 객체 지향 언어이고, 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크이고, 좋은 객체 지향 앱을 개발할 수 있게 도와주는 프레임워크라고 한다.

그렇다면 객체 지향 언어가 가진 강력한 특징은 무엇이고, 좋은 객체 지향이란 무엇인가 ?

객체 지향 프로그래밍

좋은 객체 지향이란 무엇인지 알아보기 전에 먼저 객체 지향 프로그래밍의 특징부터 알아보겠다.

객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 객체의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.
객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

결국엔 컴퓨터 프로그램이 객체의 모임으로 이루어져 있고, 각각의 객체는 독립적이기 때문에 프로그램을 유연하고 변경이 용이하게 만들 수 있다는 말이다.

그리고 이에 핵심적인 역할을 하는 것이 다형성이다.

다형성

운전자 - 자동차 예시

자동차가 아반떼에서 테슬라로 바뀐다고 해서 운전자까지 바꿀 필요는 없다.

왜 ? 운전자는 그대로 운전이 가능하니까.

→ 새로운 자동차가 나와도 클라이언트는 새로운 걸 안 배워도 되는 것

클라이언트에 영향을 주지 않고 새로운 기능을 제공할 수 있게 함

왜 ? 역할과 구현으로 구분했기 때문

그래서 이런 특징 때문에 어떤 장점이 있나 ?

핵심은 클라이언트이다.

클라이언트는 대상 역할의 인터페이스만 알면 된다.
클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.

이 특징을 자바에서는 다형성이라는 것을 통해 해결했다.

역할 = 인터페이스

구현 = 인터페이스를 구현한 클래스, 구현 객체

로 보면 된다.

그래서 객체를 설계할 때 일단 역할, 인터페이스를 설계해서 구현하고, 그 역할을 수행하는 구현 객체를 그 다음에 만드는 것

핵심은 구현보다 인터페이스가 먼저이다.

다형성의 본질은

클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

그래서 이게 스프링의 본질과 무슨 관련이 있는데 ??

스프링은 다형성을 극대화해서 이용할 수 있게 도와준다
스프링의 IoC, DI는 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 함

그리고 스프링과 객체지향 설계에 대해서 제대로 이해를 하기 위해서는

한 가지를 더 알아야 하는데, 바로 SOLID라고 하는 좋은 객체지향 설계 5가지 원칙이다.

좋은 객체지향

좋은 객체지향 설계의 5가지 원칙인 SOLID에 대해서 알아보겠다.

SRP: 단일 책임 원칙
OCP: 개방-폐쇄 원칙
LSP: 리스코프 치환 원칙
ISP: 인터페이스 분리 원칙
DIP: 의존관계 역전 원칙

SRP 단일 책임 원칙

하나의 클래스는 하나의 책임만 가져야 한다.
하나의 책임이라고 하면 애매할 수 있는데, 중요한 기준은 변경이다.

→ 변경이 있을 때 파급 효과가 적으면 SRP를 잘 따른 것
계층을 나누는 것 역시 각 계층의 책임을 분리한다는 점에서 SRP와 관련이 있다.

OCP 개방-폐쇄 원칙

소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.

→ 확장을 하려면 당연히 기존 코드에서 추가가 될 텐데, 변경에는 닫혀 있어야 한다는 말이 모순이지만, 다형성을 사용하면 가능하다. (하나의 인터페이스, 여러 개의 구현체)

근데 만약, A라는 인터페이스가 있고, 그 인터페이스를 구현한 B, C가 있다고 해보자.

그리고 D에서 B를 쓰고 있다가, C로 바꾸고 싶어졌다고 하자.

그럼 D 입장에서는 B를 쓰다가 C로 변경했기 때문에 코드의 변경이 일어난다.

어 이러면 OCP가 깨지는데 ?

즉, OCP가 깨진다는 말은, 클라이언트가 변경을 해야한다는 것임. (인터페이스를 사용했다고 해서 역할과 구현이 완전히 분리된 것은 아니라는 뜻)

원칙대로라면, 기존 코드 변경 없이 기능을 넣을 수 있어야 하는데, 그게 안 되고 있다.

이걸 해주는 게 바로 스프링 컨테이너이다.

LSP 리스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성은 깨뜨리지 않으면서, 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
다형성에서 하위 클래서는 인터페이스 규약을 모두 지켜야 한다는 것을 뜻하고, 다형성을 지원하기 위한 원칙이며, 인터페이스를 구현한 구현체를 믿고 사용하기 위해선 이 원칙이 필요하다.

예를 들면, 자동차 액셀을 밟으면 앞으로 간다는 인터페이스가 있는데

그 인터페이스를 구현한 구현체에서 속도가 -10이 되게 기능을 만들었다고 가정해보자.

컴파일 오류는 안 나지만, 이 인터페이스에는 액셀은 무조건 앞으로 가야한다는 규약이 있기 때문에

위 기능은 LSP를 위반하는 클래스이다.

ISP 인터페이스 분리 원칙

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
이로 인해 인터페이스가 명확해지고, 대체 가능성이 높아진다.

예를 들면, 자동차 인터페이스 하나 대신 운전, 정비 등등 여러 인터페이스로 분리

사용자 클라이언트를 운전자, 정비사 클라이언트 등으로 분리하는 편이 더 낫다.

즉, 기능을 적당한 크기로 잘 쪼개는 게 중요하다는 뜻

DIP 의존관계 역전 원칙

추상화에 의존해야지, 구체화에 의존하면 안 된다.
쉽게 얘기해서, 구현 클래스에 의존하지 말고 인터페이스에 의존하라는 뜻
앞서 나온 내용에서 역할과 구현 중 역할에 의존하게 해야 한다는 뜻이다.

→ 역할과 구현을 철저하게 분리해야 하는데, 그래야 시스템도 언제든지 쉽게 갈아 끼울 수 있게 되기 때문이다. 그게 가능하려면 역할에 의존해야 하고, 구현에 의존하면 절대 안 된다 !!

정리

결국, 객체지향의 핵심은 다형성이다.

근데 다형성만으로는 쉽게 부품 갈아끼우듯 개발을 할 수가 없다. (다형성만으로는 OCP, DIP를 지키기 어려움)

그래서 이를 해결하려면 객체를 사용하는 클라이언트가 아닌, 외부에서 구현 객체를 생성하고, 의존관계를 연결해주는 구조가 필요하다.

그게 바로 스프링이다 !!!

다시 스프링

스프링은 아래 기술로 다형성 + OCP, DIP를 지킬 수 있도록 해준다
- DI(Dependency Injection): 의존성 주입
- DI 컨테이너 제공
클라이언트 코드의 변경 없이 기능 확장 가능

DI 컨테이너는 자바 객체들을 컨테이너 안에 넣어놓고, 그 안에서 의존관계를 서로 연결해주고 주입해주는 기능을 제공한다.

스프링은 이 기능을 제공하도록 설계되었기 때문에 클라이언트 코드의 변경 없이 기능을 확장할 수 있다.

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

정리하자면,

스프링은 자바의 객체지향적인 특징, 그 중에서도 특히 다형성을 최대한 활용해서 좋은 객체지향 애플리케이션을 만들 수 있도록 도와주는 프레임워크라고 볼 수 있다.

역할과 구현을 분리하고 다형성을 활용하더라도, 클라이언트가 직접 구현체를 선택하면 OCP와 DIP를 지키기 어려워질 수 있다.

스프링은 DI와 IoC 컨테이너를 통해 객체의 생성과 의존관계 설정을 외부에서 담당하도록 해서 이를 편리하게 해결할 수 있도록 도와준다.

→ 이제 스프링이 왜 만들어졌는지 조금은 감이 잡히는 것 같다.