Spring
필수
스프링 프레임워크
스프링 부트: 스프링 관련 기술을 편리하게 사용할 수 있도록 지원. 최근에는 기본으로 사용
선택
스프링 데이터: CRUD 편의 기능 ex.스프링 데이터 JPA
스프링 세션
스프링 시큐리티: 보안
스프링 Rest Docs: API 문서+테스트
스프링 배치: 데이터 배치 처리
스프링 클라우드
...
스프링 단어?
-스프링 DI 컨테이너 기술(스프링 빈 관리)
-스프링 프레임워크
-스프링 부트+스프링 프레임워크 등을 모두 포함한 스프링 생태계
스프링 핵심
자바 언어 기반의 프레임 워크
객체 지향 언어가 가진 강력한 특징을 살려내는 프레임워크
객체들의 모임. 객체는 메세지를 주고받고 데이터를 처리할 수 있다. (협력)
유연하고 변경에 용이 => 컴포넌트를 쉽고 유연하게 변경하면서 개발
다형성 Polymorphism
역할(인터페이스) - 구현(클래스, 객체) 분리
클라이언트는 대상의 역할(인터페이스)만 알면 된다.
클라이언트는 구현 대상의 내부 구조를 몰라도 된다
클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다
클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
혼자 있는 객체는 없다.
클라이언트: 요청, 서버: 응답
수 많은 객체 클라이언트와 객체 서버는 서로 협력 관계를 가진다.
인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
클라이언트를 변경하지 않고 서버의 구현 기능을 유연하게 변경할 수 있다.
따라서, 인터페이스를 안정적으로 잘 설계하는 것이 중요
좋은 객체 지향 설계의 5가지 원칙 (SOLID)
by 로버트 마틴
SRP: 단일 책임 원칙 (Single Responsibility Principle)
한 클래스는 하나의 책임만 가져야 한다. 책임의 기준이란 모호
중요한 기준은 변경
변경이 있을 때 파급 효과가 적으면 good code!
OCP: 개방-폐쇄 원칙 (Open/Closed Principle)
확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
코드의 변경 없이 기능 추가 -> 다형성 활용
새로운 구현체를 만드는 것은 기존 코드의 변경이 아니다.
그러나 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다.
객체를 생성하고 연관 관계를 맺어주는 별도의 조립, 설정자가 필요하다. (스프링 컨테이너의 역할)
LSP: 리스코프 치환 원칙 (Liskov Substitution Principle)
다형성에서 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
단순히 컴파일의 성공을 넘어서는 이야기
인터페이스 규약에서 정한 기능이 모두 작동하도록 구현
ISP: 인터페이스 분리 원칙 (Interface Segregation Principle)
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
인터페이스의 분리 = 클라이언트의 분리
기능을 잘 쪼개는 것이 중요
인터페이스가 명확해지고 대체 가능성이 높아진다.
DIP: 의존관계 역전 원칙 (Dependency Inversion Principle)
프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다.
구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻
클라이언트가 직접 구현 객체를 생성 -> 구현 객체를 변경할 때 클라이언트 코드도 함께 변경 => DIP 위반
다시 스프링으로
스프링은 다음 기술로 다형성+OCP, DIP를 가능하게 지원
-DI(Dependency Injection): 의존관계, 의존성 주입
-DI 컨테이너 제공
클라이언트 코드의 변경 없이 기능 확장
쉽게 부품을 교체하듯이 개발
정리
이상적으로는 모든 설계에 인터페이스를 부여하자.
구현 기술이 바뀌더라도 변경의 범위가 작고 유연해진다.
실무 고민: 추상화라는 비용이 발생. 기능을 확장할 가능성이 없다면 구체 클래스를 직접 사용하고, 향후 꼭 필요할 때 리팩터링해서 인터페이스를 도입하는 것도 방법이다.
책 추천
객체지향: 객체지향의 사실과 오해
스프링: 토비의 스프링 3.1
JPA: 자바 ORM 표준 JPA 프로그래밍
