728x90
1. EJB
- 단점 : 웹 관련 기술과 ORM의 기술을 제공하지만 너무 복잡하고 EJB에 의존적
- 대안책 : 스프링(웹 관련 기술), 하이버네이트(ORM 기술 == JPA)
- 스프링 : EJB 없이도 자바로만 가지고 충분히 고품질의 확장 가능한 애플리케이션 개발할 수 있음을 보여줌.
- EJB 컨테이너 대체
- 단순함
- 현재 표준 기술
- 하이버네이트(JPA) : 하이버네이트 JPA의 새로운 표준 정의
- EJB EntityBean 기술 대체
- JPA 표준 정의
- EJB EntityBean -> 하이버네이트 -> JPA(인터페이스)
- JPA의 90%는 하이버네이트로 구현
- 스프링 : EJB 없이도 자바로만 가지고 충분히 고품질의 확장 가능한 애플리케이션 개발할 수 있음을 보여줌.
2. Spring
- 하나가 아닌 여러기능들의 모음
2.1. Spring Framework
- Spring의 여러 기능들 중 핵심
- 핵심 기술 : 스프링 DI 컨테이너(bean 관리), AOP
- 웹 기술: 스프링 mvc, 스프링 webFlux
- 데이터 접근 기술: 트랜잭션, JDBC, ORM 지원, XML 지원
- 기술 통합: 캐시, 이메일, 원격접근, 스케줄링
- 테스트: 스프링 기반 테스트 지원
- 언어: 코틀린, 그루비
2.2. Spring Boot
- 스프링을 편리하게 사용할 수 있도록 지원, 최근에는 기본으로 사용 = spring framwork를 boot를 통해서 편리하게 사용
- 단독으로 실행할 수 있는 스프링 애플리케이션을 쉽게 생성
- Tomcat 같은 웹 서버를 내장해서 별도의 웹 서버를 설치하지 않아도 됨
- 손쉬운 빌드 구성을 위한 starter 종속성 제공 : dependence로 library 다 가져옴
- 스프링과 3rd parth(외부) 라이브러리 자동 구성 : version을 자기가 지정해줌
- 메트릭, 상태 확인, 외부 구성 같은 프로덕션 준비 기능 제공: 모니터링을 어느정도 제공
- 관례에 의한 간결한 설정
3. Spring 핵심
- 핵심으로 나오는 결과
- 웹 애플리케이션 - DB 접근 용이성 - 전자정부 프레임워크 - 웹서버 자동 실행 - 핵심
- Spring은 Java 언어 기반 framework -> Java는 OOP 언어
- Spring은 OOP언어가 가진 특징을 살려내는 framework
- Spring은 좋은 객체 지향 애플리케이션을 개발할 수 있게 도와주는 framework
4. 좋은 객체 지향 프로그래밍이란
4.1. 객체 지향 특징
- 추상화 캡슐화 상속 다형성
- 객체 지향 프로그래밍은 프로그램을 유연하고 변경이 용이하게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용
4.2. 다형성
- 역할과 구현
- 자동차가 바뀌어도 면허증이 있으면 운전 가능 (역할: 면허증, 구현: 자동차)
- 연극의 대본이 있으면 배우가 누군지 상관없이 연극 가능 (역할: 대본 , 구현: 배우)
- 역할과 구현 분리의 장점 : 변경에 유연
- 클라이언트는 대상의 역할(인터페이스)만 알면 된다.
- 클라이언트는 구현 대상의 내부 구조를 몰라도 된다.
- 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않는다.
- 클라이언트는 구현 대상 자체를 변경해도 영향을 받지 않는다.
- 역할과 구현 분리 (Java)
- Java의 다형성 활용
- 역할 : 인터페이스 구현 : 인터페이스를 구현한 클래스, 구현 객체
- 객체를 설계할 때 역할과 구현을 명확히 분리
- 객체 설계시 역할(인터페이스)을 먼저 부여하고, 그 역할을 수행하는 구현 객체 만들기 - 좋은 객체 지향 프로그래밍
cf) 항상 인터페이스를 만드는 것은 아님. 변경할 일이 없으면 바로 구현체를 생성하는 것이 비용적 측면에서 유리
4.3. 객체의 협력
- 혼자 있는 객체는 없다.
- 수많은 객체 클라이언트와 객체 서버는 서로 협력관계를 가진다.
4.4. 예시
public class MemberService {
// private MemberRepository memberRepository = new MemoryMemberRepository();
private MemberRepository memberRepository = new JDBCMemberRepository();
}
4.5. 다형성의 본질
- 인터페이스를 구현한 객체 인스턴스를 실행 시점에 유연하게 변경할 수 있다.
- 다형성의 본질을 이해하려면 협력이라는 객체 사이의 관계에서 시작
- 클라이언트를 변경하지 않고, 서버의 구현 기능을 유연하게 변경할 수 있다.
- 결론 : 인터페이스를 안정적으로 잘 설계하는 것이 중요
5. 스프링과 객체 지향
- 스프링에서 이야기하는 제어의 역전(IoC), 의존관계 주입(DI)은 다형성을 활용해서 역할과 구현을 편리하게 다룰 수 있도록 지원
5.1. SOLID : 좋은 객체 지향 설계 5가지 원칙
SRP: 단일 책임 원칙(single responsibility principle)
OCP: 개방-폐쇄 원칙 (Open/closed principle)
LSP: 리스코프 치환 원칙 (Liskov substitution principle)
ISP: 인터페이스 분리 원칙 (Interface segregation principle)
DIP: 의존관계 역전 원칙 (Dependency inversion principle)
5.1.1. SRP (단일 체계 원칙)
- 한 클래스는 하나의 책임만 가져야 한다. (기준이 모호)
- 중요 기준 : 변경 - 변경이 있을 때 파급 효과가 적게 책임을 줄인다.
5.1.2. OCP (개방 폐쇄 원칙)
- 확장에는 열려 있고 변경에는 닫혀 있어야한다.
- 예시
public class MemberService {
// private MemberRepository memberRepository = new MemoryMemberRepository(); // 기존 코드
private MemberRepository memberRepository = new JDBCMemberRepository(); //변경 코드 -> 구현 객체를 변경하려면 클라이언트 코드를 변경 필요
}
문제점 : 다형성을 적용했지만 OCP 원칙을 지킬 수 없다. MemberService라는 client 코드를 건들여야 하기 때문
해결 : 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요 -> DI, IOC 가 필요 -> spring container가 가짐
5.1.3. LSP (리스코프 치환 원칙)
- 기능적으로 interface 규약을 지켜주는것
- 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. ex) Template method pattern
== 부모가 바뀌다고 자손이 영향을 받으면 안됨
5.1.4. ISP (인터페이스 분리 원칙)
- 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
- 분리가 되어야지 변경이 발생시, 영향을 안받는다.
- 인터페이스가 명확해지고, 대체 가능성이 높아진다.
5.1.5.DIP (의존관계 역전)
- 구현 클래스에 의존하지 말고, 인터페이스에 의존
- (5.1.2. OCP 예시) MemberService
- MemberService는 인터페이스에 의존하지만, 구현 클래스도 동시에 의존한다.
- MemberService 클라이언트가 구현 클래스를 직접 선택 -> DIP 위반
6. 정리
- 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
- 다형성만으로는 OCP, DIP를 지킬 수 없다.
- Spring의 DI, IOC, Container가 필요
7. 객체 지향 설계와 스프링
- 스프링은 1) DI와 2) DI Container 기술로 다형성과 OCP, DIP를 가능하게 지원
- DI(Dependency Injection) : 의존관계, 의존성 주입
- DI 컨테이너 제공 - Bean 관리
- client code 변경 없이 기능 확장 cf) 클라이언트 코드를 변경안하는거지 서버 코드는 설정처럼 건들여야한다.
- 인터페이스는 추상화라는 비용이 발생하기 때문에 기능을 확장할 가능성이 없으면 구체클래스를 사용하고 향후 필요할 경우에 리팩토링을 해서 인터페이스를 도입하는 방법도 있다.
출처: 인프런 스프링 핵심 원리 - 기본편
