[스프링 핵심 원리 - 기본편] #1. 객체 지향 설계와 스프링

[6om1n]

스프링이란?

• 스프링은 어떤 특정한 하나가 아니라 여러가지 기술들의 모음 이다.
• 스프링의 가장 핵심인 스프링 프레임워크, 여러 스프링 기술들을 편리하게 사용할 수 있도록 도와주는 스프링 부트, 스프링 데이터, 세션, 시큐리티, 클라우드 등등이 있다.

스프링 프레임워크

• 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트
• 웹 기술 : 스프링 MVC, 스프링 WebFlux
• 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
• 기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
• 테스트 : 스프링 기반 테스트 지원
• 언어 : 코틀린, 그루비
• 최근에는 스프링 부트를 통해서 스프링 프레임워크의 기술들을 편리하게 사용

스프링 부트

• 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
• 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
• Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 된다.
• 손쉬운 빌드 구성을 위한 starter 종속성 제공
• 스프링과 외부 라이브러리 자동 구성

스프링

• 스프링 단어는 문맥에 따라 다르게 사용된다.

  • 스프링 DI 컨테이너 기술
  • 스프링 프레임워크
  • 스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계

• 복잡하게 보여도 핵심 기술은 단순하다.

스프링의 진짜 핵심

• 스프링은 자바 언어 기반의 프레임워크
• 자바 언어의 가장 큰 특징 - 객체 지향 언어
• 스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
• 스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크

---

좋은 객체 지향 프로그래밍이란?

• 객체 지향의 특징

  • 추상화
  • 캡슐화
  • 상속
  • 다형성

• 객체 지향 프로그래밍은 컴퓨터 프로그램을 객체 들의 모임 으로 파악하는 것이다.

• 각각의 객체 는 메시지 를 주고 받고, 데이터를 처리할 수 있다.

• 객체 지향 프로그래밍은 프로그램을 유연 하고 변경 이 용이하게 만들기에 대규모 소프트웨어 개발에 많이 사용된다.

다형성

• 실세계와 객체 지향은 1:1로 매칭은 잘 안된다. 그래도 실세계의 비유로 이해하기는 좋다.
• 세상을 역할 과 역할을 직접 행하는 구현 으로 세상을 구분한다.
• 역할 (= 인터페이스) , 구현 (=인터페이스를 구현한 개체)

운전자 - 자동차 예제

• 운전자와 자동차라는 역할이 있을 때 자동차 역할을 3개의 다른 자동차로 구현을 했다.
• K3 라는 자동차가 구현하고, 아반떼라는 자동차가 구현을 했을 때 자동차가 바뀌어도 운전을 할 수 있다.
• 자동차 역할의 인터페이스를 따라서 자동차를 구현했기 때문이다.
• 운전자는 자동차 인터페이스에 대해서만 알고 있다. (자동차 역할에 대해서만 의존하고있다.)
• 이렇게 할 경우, 클라이언트에 영향을 주지 않고 새로운 기능을 제공할 수 있는 것이다.
• 역할과 구현으로 세상을 구분했기 때문에 가능한 일이다!

공연 무대 - 로미오와 줄리엣 공연

• 운전자-자동차 예제와 마찬가지로 로미오라는 역할, 줄리엣이라는 역할이 있고 그 역할을 맡은 배우는 대체가 가능해야한다.
• 이런 식으로 내부 구조를 몰라도 역할과 구현을 나누면 변경 가능한 대체 가능성이 생긴다.
• 이것이 바로 유연하고 변경에 용이하다는 뜻이다.

역할과 구현을 분리

• 역할 과 구현 으로 구분하면 세상이 단순해지고, 유연해지며, 변경도 편리 해진다.
• 클라이언트는 구현 대상의 내부 구조를 몰라도 되고, 대상의 역할인 인터페이스 만 알면 된다.
• 또한 클라이언트 는 구현 대상의 내부 구조가 변경 되어도 영향을 받지 않고, 대상 자체를 변경 해도 영향을 받지 않는다.
• 자바에서의 역할은 인터페이스 이며, 구현은 인터페이스를 구현한 클래스 이다.

객체의 협력 관계라고 생각

• 클라이언트는 요청하는 사람, 서버는 요청을 받아서 응답하는 사람이다.
• 수많은 객체 클라이언트와 객체 서버가 서로 협력 관계를 가진다.

• 클라이언트가 서버에게 요청하는 그림이며, 클라이언트가 서버한테 요청을 하면 서버가 또 다른 클라이언트가 되어 다른 서버에게 요청할 수도 있다.

• MemberRepository 에서 save 를 호출하면 현재 MemoryMemberRepository 에 들어가있으면 거기에 있는 save 가 호출이 되고, JdbcMemberRepository 에 있으면 거기에 있는 save 가 호출이 된다. 이것을 오버라이딩 이라고 하고, 다형성 이 가지고 있는 장점이다.
• 클라이언트가 파란색인데, 받는 서버를 빨간색으로 바꿀 수 있고 초록색으로도 바꿀 수 있다. 이것이 다형성의 본질 이다.

다형성의 본질

• 인터페이스를 구현한 객체 인스턴스를 실행 시점 에 유연하게 변경 할 수 있다.
• 다형성의 본질을 이해하려면 협력 이라는 객체 사이의 관계에서 시작 해야 한다.
• 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.

역할과 구현을 분리하는 것의 한계

• 역할 (인터페이스) 자체가 변하면, 클라이언트, 서버 모두에 큰 변경이 발생한다.

스프링과 객체 지향

• 다형성이 가장 중요하며, 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
• 스프링에서 이야기하는 제어의 역전(IoC), 의존 관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
• 스프링을 사용하면 구현을 편리하게 변경할 수 있다.

---

좋은 객체 지향 설계의 5가지 원칙 (SOLID)

SRP 단일 책임 원칙 (Single responsibility principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임이라는 것은 모호하다. -> 크거나 작을 수 있고, 문맥과 상황에 따라 달라진다.
• 중요한 기준은 변경 이다. 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른 것이라고 볼 수 있다.

OCP 개방-폐쇄 원칙 (Open/closed principle)

• 가장 중요한 원칙이다.
• 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀 있어야 한다.
• 이해가 안 될 수 있지만, 위의 운전자-자동차 예시에서 K3에서 테슬라로 바뀌어도 운전자는 운전을 할 수 있고 공연도 마찬가지고 다른 배우가 동일한 배역을 맡아도 공연은 진행이 된다. 이 것이 바로 개방 폐쇄의 원칙이다.
• 인터페이스를 구현한 새로운 클래스 하나 만들어서 새로운 기능을 구현하는 것은 기존 코드를 변경하는 것이 아니다.
• 다형성 을 활용하면 소프트웨어를 확장에는 열려있으나 변경에는 닫혀있게 할 수 있다.

• MemberService 클라이언트가 구현 클래스를 직접 선택한다.
• 하지만 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
• 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
• 이런 관계를 맺어 별도의 조립을 해주는 설정자가 필요한데, 그것을 스프링 컨테이너 가 해준다.

LSP 리스코프 치환 원칙 (Liskov substitution principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체를 믿고 사용하려면 리스코프 치환 원칙이 필요하다.
• 인터페이스 규약을 무조건 지켜야한다.
• ex) 엑셀을 구현할 때 느리더라도 앞으로 가는 엑셀을 구현 해야한다. (뒤로 가면 안된다.)

ISP 인터페이스 분리 원칙

• 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
• 자동차 인터페이스를 운전 인터페이스, 정비 인터페이스로 분리한다.
• 사용자 클라이언트를 운전자 클라이언트, 정비사 클라이언트로 분리한다.
• 분리하게 되면 정비 인터페이스 자체가 변해도 운전자 클라이언트에게 영향을 주지 않는다.
• 즉, 인터페이스가 명확해지고, 대체 가능성이 높아진다.

DIP 의존 관계 역전 원칙

• 제일 중요한 원칙
• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다." 의존성 주입은 이 원칙을 따르는 방법 중 하나이다.
• 즉, 위의 코드에서 MemberService 는 MemberRepository 인터페이스만을 바라보고 MemoryMemberRepository 나 JdbcMemberRepository 에 대해서는 몰라야 된다는 의미와 같다.
• 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻이다.
• ex) 운전자는 자동자의 역할에 대해 알아야지 K3 에 대해서는 디테일하게 몰라도 된다. 중요한 것은 역할에 대해 알아야하는 것이다.
• 앞선 예에서 역할에 의존하게 해야 한다는 것과 같은 말이다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.
• 구현체에 의존하게 되면 변경이 아주 어려워진다.!!

• OCP 예에서 MemberService 는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
• MemberService 클라이언트가 구현 클래스를 직접 선택하기 때문에 DIP에 위반된다.

정리

• 객체 지향의 핵심은 다형성
• 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성 만으로는 OCP, DIP를 지킬 수 없다.
• => 따라서 스프링 이 필요하다 !!

[chaelink]

그림을 잘 넣어주셔서 이해가 잘 되는 것 같아요! 수고 많으셨습니당!

[Pracrobo]

정리 잘하시네요!!! 이따 뵙겠습니다 !