1. 스프링이란 ?
- 스프링 생태계
스프링은 어떤 특정한 하나가 아니라 여러가지 기술들의 모음이다.
(스프링 프레임워크, 부트, 데이터, 세션, 시큐리티, Rest Docs, 배치, 클라우드 등등)
- spring.io -> 프로젝트 -> 오버뷰 에 보면 굉장히 많은 스프링과 관련된 프로젝트가 있다.
핵심은 스프링 프레임워크.
이 모든 기술들을 편리하게 사용할 수 있도록 도와주는게 스프링부트.
스프링 프레임워크
핵심기술 : 스프링 DI 컨테이너, AOP, 이벤트,
웹기술 : 스프링 MVC, 스프링 WebFlux
데이터 접근 기술 : 트랜잭션, JDBC, ORM 지원, XML 지원
기술 통합 : 캐시, 이메일, 원격접근, 스케줄링
테스트 : 스프링 기반 테스트 지원
언어 : 코틀린, 그루비
스프링 부트
스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용
단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
-> Tomcat 같은 웹서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨.
손쉬운 빌드 구성을 위한 starter 종석성 제공 -> 이 라이브러리 저 라이브러리 사용하고 했어야 했는데 라이브러리를 손쉽게 땡겨 쓸 수 있다.
외부라이브러리 버전에 대해 고민하지 않아도 된다.
메트릭(모니터링), 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공
관례에 의한 간결한 설정
스프링 단어 ?
스프링이라는 단어는 문맥에 따라 다르게 사용된다
스프링 DI 컨테이너 기술
스프링 프레임워크
스프링 부트, 스프링 프레임워크 등을 모두 포함한 스프링 생태계 -> 이게 거의 맞는 말 인듯
스프링은 왜 만들었나요 ?
핵심 개념 : 이 기술을 왜 만들었는가 ? / 이 기술의 핵심 컨셉은 ?
웹 애플리케이션 만들고, DB 접근 편리하게 해주는 기술 ?
전자정부 프레임워크 ?
웹 서버도 자동으로 띄워주고?
클라우드, 마이크로서비스 ?
이런건 다 결과물이다. 이런거 때문에 쓰는건 맞긴한데 암튼 일단..
스프링의 진짜 핵심
스프링은 자바 언어 기반의 프레임워크
자바 언어의 가장 큰 특징 - 객체 지향 언어
스프링은 객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
스프링은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 프레임워크
2. 좋은 객체 지향 프로그래밍이란 ?
객체 지향 특징 : 추상화 캡슐화 상속 다형성 등등등
객체 지향 프로그래밍
-객체 지향 프로그래밍은 컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러개의 독립된 단위, 즉 "객체"들의 모임으로 파악하고자 하는 것이다. 각각의 객체는 메시지를 주고받고, 데이터를 처리할 수 있다.(협력)
-객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.
객체들의 모임. 객체는 메시지를 주고받고 데이터를 처리할 수 있다
유연하고 변경에 용이하다.
아무튼 그렇다고 한다!
유연하고, 변경이 용이?
- 레고 블럭 조립하듯이 / 키보드, 마우스 갈아 끼우듯이 / 컴퓨터 부품 갈아 끼우듯이 / 컴포넌트를 쉽고 유연하게 변경하면서 개발할 수 있는 방법
-> 다형성(Polymorphism)
다형성의 실세계 비유
- 실세계와 객체 지향을 1:1로 매칭 x
- 그래도 실세계의 비유로 이해하기에는 좋음
- 역할과 구현으로 세상을 구분
운전자 - 자동차
운전자라는 역할이 있고 자동차라는 역할이 있다. 자동차 역할에도 k3, 아반떼, 테슬라 모델 3 같이 자동차 구현을 했다.
운전자는 k3 든 아반떼든 테슬라든 자동차가 바뀌어도 운전자는 다 운전할 수 있다.
즉 자동차가 바뀌더라도 운전자한테 영향을 주지 않는다. 내가 테슬라를 탄다고 해서 새로운 운전면허를 안 따도 되듯이.
자동차 역할을 만들고 그 구현을 분리한 것은 운전자를 위해서 한 것이다.
운전자를 client 라고 해보자. 이 client 는 자동차의 내부 구조를 몰라도 된다. 그냥 자동차 역할만 잘 수행하고 있으면 된다. 아반떼를 테슬라 모델3로 바꿔도 운전자는 바뀔 필요가 없이 그대로 운전할 수 있다. 완전히 새로운 차가 나와도 기존 자동차역할을 할 수 있으면 된다. 자동차 세상을 무한히 확장 가능하다. 기름자동차에서 전기자동차가 나왔더라도 그대로 운전할 수 있다. 좀 더 디테일하게 얘기해보면 클라이언트에게 영향을 주지 않고 세상을 무한히 확장시킬 수 있다.
공연 무대 - 로미오와 줄리엣
로미오라는 역할, 줄리엣이라는 역할이 있다. 로미오 역할은 장동건 원빈 등이 할 수 있고 줄리엣 역할은 김태희 송혜교 등 할 수 있다. 그 공연은 꼭 로미오 역할에 누구든지 할 수 있고 줄리엣 역할 또한 누구든 할 수 있다. 로미오 역할 하는 사람은 줄리엣 역할을 누가 하든 상관없다. 로미오가 클라이언트, 줄리엣 서버라고 해보자. 역할들은 언제든 대체가 가능하기 때문에 유연하고 변경이 가능하다라는 것이다.
역할과 구현을 분리
- 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며 변경도 편리해진다.
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
- 자바언어로 보면..
- 자바 언어의 다형성을 활용 : 역할 = 인터페이스 / 구현 = 인터페이스를 구현한 클래스, 구현 객체
- 객체를 설계할 때 역할과 구현을 명확히 분리
객체의 협력이라는 관계부터 생각
- 혼자 있는 객체는 없다.
- 클라이언트 : 요청 / 서버 : 응답
- 수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.
자바 에서는 다형성을 어떻게 구현을 했나.
- 오버라이딩
- 다형성으로 인터페이스를 구현한 객체를 실행 시점에 유연하게 변경할 수 있다.
- 물론 클래스 상속 관계도 다형성, 오버라이딩 적용 가능
다형성의 본질
- 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
- 다형성의 본질을 이해하려면 협력이라는 객체사이의 관계에서 시작해야함.
- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
역할과 구현을 분리
- 실세계의 역할과 구현이라는 편리한 컨셉을 다형성을 통해 객체 세상으로 가져올 수 있음.
- 유연하고 변경이 용이
- 확장 가능한 설계
- 클라이언트에 영향을 주지 않는변경 가능
- 인터페이스를 안정적으로 잘 설계하는 것이 중요
스프링과 객체 지향
- 다형성이 가장 중요하다
- 스프링은 다형성을 극대화해서 이용할 수 있게 도와준다.
- 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주임(DI) 는 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원한다.
- 스프링을 사용하면 마치 레고 블럭 조립하듯이, 공연 무대의 배우를 선택하듯이, 구현을 편리하게 변경할 수 있다.
3. 좋은 객체 지향 설계의 5가지 원칙(SOLID) - 면접에서 많이 나옴
SOLID : 클린코드로 유명한 로버트 마틴이 좋은 객체 지향 설계의 5가지 원칙을 정리
SRP : 단일 책임 원칙 (single responsibility principle)
OCP : 개방-폐쇄 원칙 (Open/closed principle)
LSP : 리스코프 치환 원칙 (Liskov substitution principle)
ISP : 인터페이스 분리 원칙 (Interface segregation principle)
DIP : 의존관계 역전 원칙 (Dependency inversion principle)
SRP : 단일 책임 원칙 (single responsibility principle)
- 한 클래스는 하나의 책임만 가져야 한다.
- 근데, 하나의 책임이라는 것은 실무에는 모호하다 : 클 수 있고, 작을 수 있다 / 문맥과 상황에 따라 다르다
- 중요한 기준은 변경이다. 변경이 있을 때 파급효과가 적으면 단일 책임 원칙을 잘 따른 것
EX) UI 변경, 객체의 생성과 사용을 분리
OCP : 개방-폐쇄 원칙 (Open/closed principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 구라 같은데 ? 확장을 하려면, 당연히 기존 코드를 변경해야되는데 ..?
- 다형성을 활용해보자
- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
- 지금까지 배운 역할과 구현의 분리를 생각해보자.
OCP : 개방-폐쇄 원칙 의 문제점
- MemberService 클라이언트가 구현 클래스를 직접 선택
MemberRepository m = new MemoryMemberRepository(); // 기존 코드
MemberRepository m = new JdbcMemberRepository(); // 변경 코드
- 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
- 분명 다형성을 사용했지만 OCP 원칙을 지킬 수 없다.
- 이 문제를 어떻게 해결해야 하나 ?
- 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다. (Spring Container 가 해줌)
LSP : 리스코프 치환 원칙 (Liskov substitution principle)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
- 단순히 컴파일에 성공하는 것을 넘어서는 이야기
- 예) 자동차 인터페이스의 엑셀은 앞으로 가라는 기능, 뒤로 가게 구현하면 LSP 위반, 느리더라도 앞으로 가야함
- 기능적으로 보장을 해줘야 된다는 말임. 컴파일만 된다고 해서 끝이 아니라는 뜻.
ISP : 인터페이스 분리 원칙 (Interface segregation principle)
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 자동차 인터페이스 -> 운전 인터페이스, 정비 인터페이스로 분리
- 사용자 클라이언트 -> 운전자 클라이언트, 정비사 클라이언트로 분리
- 분리하면 정비 인터페이스 자체가 변해도 운전자 클라이언트에 영향을 주지 않음.
- 인터페이스가 명확해지고, 대체 가능성이 높아진다.
DIP : 의존관계 역전 원칙 (Dependency inversion principle)
- 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다" 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
- 쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
- 앞에서 이야기한 역할(Role)에 의존하게 해야 한다는 것과 같다. 객체 세상도 클라이언트가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다. 구현체에 의존하게 되면 변경이 아주 어려워진다.
- 그런데 OCP에 설명한 MemberService 는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
- MemberService 클라이언트가 구현 클래스를 직접 선택
MemberRepository m = new MemoryMemberRepository();
- DIP 위반
정리
- 객체 지향의 핵심은 다형성
- 다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
- 다형성 만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
- 다형성 만으로는 OCP,DIP 를 지킬 수 없다.
- 뭔가가 더 필요함....
4. 객체 지향 설계와 스프링
스프링 이야기에 왜 객체 지향 이야기가 나오는 것일까 ?
- 스프링은 다음 기술로 다형성 + OCP,DIP를 가능하게 지원
DI (Dependency Injection) : 의존관계, 의존성 주입
DI 컨테이너 제공
- 클라이언트 코드의 변경 없이 기능 확장
- 쉽게 부품을 교체하듯이 개발
스프링이 없던 시절로
- 옛날 어떤 개발자가 좋은 객체 지향 개발을 하려고 OCP, DIP 원칙을 지키면서 개발을 해보니, 너무 할일이 많았다. 배보다 배꼽이 크다. 그래서 프레임워크로 만들어버렸다.
- 순수하게 자바로 OCP,DIP 원칙들을 지키면서 개발을 해보면, 결국 스프링 프레임워크를 만들게 된다. (더 정확히는 DI 컨테이너)
- DI 개념은 말로는 설명해도 이해가 잘 안됌. 코드로 짜봐야 됨
정리
- 모든 설계에 역할과 구현을 분리하자.
- 자동차, 로미오와 줄리엣의 예를 떠올려보자.
- 애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다.
- 이상적으로는 모든 설계에 인터페이스를 부여하자.