[작성일: 2023. 05. 30]
스프링이란?
스프링 프레임워크
- 핵심 기술 : 스프링 DI 컨테이너, AOP, 이벤트, 기타
- 웹 기술 : 스프링 MVC, 스프링 WebFlux
- 데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합 : 캐시, 이메일, 원격 접근, 스케줄링
- 테스트 : 스프링 기반 테스트 지원
- 언어 : 코틀린, 그루비
- 최근에는 스프링 부트를 통해 스프링 프레임워크의 기술들을 편리하게 사용하고 있음.
스프링 부트
- 스프링을 편리하게 사용할 수 있도록 지원하며 최근에는 기본으로 사용하고 있다.
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성한다.
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 된다.
- 쉬운 빌드 구성을 위한 starter 종속성을 제공한다.(라이브러리 관련)
- 스프링과 3rd parth(외부) 라이브러리를 자동으로 구성한다.(라이브러리 version 지정 등)
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능을 제공한다.
- 관례에 의한 간결한 설정이 가능하다.
스프링의 핵심
- 스프링은 자바 언어(객체지향 언어) 기반의 프레임워크
- 스프링은 객체 지향 언어가 가진 강력한 특징을 잘 살려내고, 좋은 객체 지향 어플리케이션을 개발할 수 있게 도와주는 프레임워크이다.
- 스프링에서 이야기하는 제어의 역전(IoC), 의존 관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
- 스프링을 사용하면 마치 레고 블럭을 조립하듯이, 공연 무대의 배우를 선택하듯이 구현을 편리하게 변경할 수 있다.
좋은 객체 지향 프로그래밍이란?
다형성(Polymorphism)
- 다형성을 실세계로 비유해보자. (역할과 구현)
- 운전자 - 자동차
- 공연 무대
- 키보드, 마우스, 세상의 표준 인터페이스들
- 정렬 알고리즘
- 할인 정책 로직 등
운전자 - 자동차
- 운전자는 K3를 타다가 아반떼로 바꿔도 운전자의 운전실력에 영향없이 운전을 할 수 있다. (유연하고 변경에 용이하다.)
- 다른 차를 산다고 해서 다른 운전 면허를 취득하지 않아도 된다.
- 자동차 역할의 인터페이스에 따라 자동차를 구현했고 운전자는 자동차의 인터페이스(역할)에만 의존하면 된다.
공연 무대(로미오와 줄리엣 공연)
- 공연 할 때 배우는 대체가 가능해야 한다.
- 로미오 역할을 맡은 사람은 줄리엣 역할을 누가 맡았는지 알 필요가 없다.
역할과 구현을 분리
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
- 역할(인터페이스), 구현(인터페이스를 구현한 클래스, 구현 객체)
- 객체를 설계할 때 역할과 구현을 명확히 분리
- 객체 설계시 역할을 먼저 부여하고 그 역할을 수행하는 구현 객체 만들기
- 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있다.
- 유연하고 변경에 용이, 확장 가능한 설계가 가능하다.
- 클라이언트에 영향을 주지 않는 변경이 가능하다.
- 인터페이스를 안정적으로 잘 설계하는 것이 중요하다.
SOLID 원칙
로버트 마틴의 좋은 객체 지향 설계의 5가지 원칙
- SRP(Single Responsibility Principle) : 단일 책임의 원칙
- 한 클래스는 하나의 책임만 가져야 한다.
- 변경이 있을 때 파급 효과가 적다면 단일 책임 원칙을 잘 따른 것
- UI 변경, 객체의 생성과 사용을 분리
- OCP(Open/Closed Principle) : 개방-폐쇄의 원칙
- 소프트웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다.
- 다형성 활용
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현한다.
- 다형성을 사용해서 OCP 원칙을 지키려면 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.
- LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
- 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- ex) 자동차 인터페이스의 엑셀은 앞으로 가는 기능만, 뒤로 가게 구현하면 컴파일 오류는 아니지만 LSP 위반, 느리더라도 앞으로만 가야함.
- ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- ex) 자동차 인터페이스는 운전 인터페이스와 정비 인터페이스로 분리한다.
- ex) 사용자 클라이언트는 운전자 클라이언트와 정비사 클라이언트로 분리한다.
- DIP(Dependency Inversion Principle) : 의존관계 역전 원칙
- 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다.
- 프로그래머는 추상화에 의존해야지 구체화에 의존하면 안 된다.
객체 지향 설계와 스프링
스프링 Point
- 스프링은 다형성 + OCP, DIP를 가능하게 지원한다.
- DI(Dependency Injection) : 의존관계, 의존성 주입
- DI 컨테이너 제공
- 클라이언트 코드의 변경 없이 기능을 확장한다.
- 모든 설계에 역할과 구현을 분리해야 한다.
- 이상적인 것은 모든 설계에 인터페이스를 부여하는 것이다. (추상화 비용 발생)
- 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고, 꼭 필요할 때 리팩토링해서 인터페이스를 도입하는 것도 하나의 방법이다.
🐣 출처: 인프런 김영한님 강의
이 글은 인프런의 김영한님 스프링 강의를 보고 작성한 글입니다.
강의를 들으면서 정리한 글이므로 틀린 내용이나 오타가 있을 수 있습니다.