EJB (Enterprise Java Beans), 예전에는 EJB를 통해 웹 프로그래밍을 했는데, 너무 복잡
-> POJO(Plain Old Java Object) 가 나와 예전으로 돌아가자는 얘기가 나올 정도
-> 로드 존슨의 책 + 하이버네이트로 EJB없이 웹 프로그래밍 대두
-> 이를 바탕으로 오픈 소스 스프링이 개발되게 됨
-> 스프링 프레임워크의 핵심 기능 ? 좋은 객체 지향 웹 프로그래밍을 가능하게 함
-> 다형성, 인터페이스 (클라이언트 중심으로 역할과 구현으로 구분함으로써 클라이언트를 변경하지 않고 서버 내부
구현만 바꿀 수 있게 됨)
-> 스프링 - 객체 지향 에서는 다형성이 가장 중요하다. 인터페이스를 잘 구성하는 것이 중요(구현 내용은 바꾸면 되지만 역할이 바뀌면
새로운 인터페이스가 필요하기 때문)
- SOLID
좋은 객체 지향 프로그래밍의 5원칙
SRP : 단일 책임 원칙
한 클래스는 하나의 책임만 가짐
객체의 생성과 사용을 구분
*OCP : 개방-폐쇄 원칙
sw요소는 확장에는 열려있으나 변경에는 닫혀있어야한다.
다형성을 활용
그런데 MemberRepository m = new Mem~~
MemberRepository m= new JdbcME~~
코드 변경이 필요해서 이 경우는 OCP원칙 지킬 수 없ㄷ다. >> 스프링 컨테이너, DI가 필요한 것!!!!
LSP리스코프 치환 원칙
객체는 프로그램의 정확성을 깨뜨려서는 안된다.
ISP 인터페이스 분리 원칙
자동차 인터페이스 > 운전 인터페이스 + 정비 인터페이스
*DIP 의존관계 역전 원칙
프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다."
구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻(다형성, 역할에 의존하라!!)
but MemberRepository m = new MemoryMemberRepository(); >>>> DIP위반(MemberService가 인터페이스와
구현 클래스를 직접 선택하고 있기에, 둘다 의존 중)
정리
객체 지향의 핵심은 다형성
다형성 만으로는 쉽게 부품을 갈아 끼우듯이 개발은 불가 (OCP, DIP 위반)
스프링은 다형성 + OCP,DIP를 가능케 함
- DI
- DI 컨테이너 제공
최종 정리
모든 설계에 역할과 구현을 분리
언제든 구현체가 유연하게 변경될 수 있도록 만드는 것이 좋은 객체 지향 설계이다.
하지만 인터페이스를 도입하면 추상화라는 비용이 발생.
객체 지향의 핵심은 "역할과 구현을 분리하라!"
좋은 객체 지향의 5원칙, SOLID
S :
SRP (Single Responsibility Principal) 단일 책임 원칙
O :
OCP (Open Close Principal) 개방 폐쇄 원칙
L :
LSP (The Liskov Substitution Principal) 리스코프 치환 원칙
I :
ISP (Interface Segregation Principal) 인터페이스 분리 원칙
D :
DIP (Dependency Inversion Principal) 의존성 역전 원칙
OCP, DIP를 위반한다.
-> OCP : 확장에는 열려있고, 변경에는 닫혀있다.
요구사항의 변동으로 DB 저장소가 Memory > JPA로 바뀌었다고 하면, MemberServiceImpl 클래스에서 new MemoryMemberRepository() -> new JpaMemberRepository()로 코드를 변경해야 할 것이다. 이는 OCP에 위반이다.
-> DIP : 추상화에 의존해야지, 구현체에 의존하지 않아야 한다.
현재 MemberServiceImpl 클래스는 MemberRepository라는 인터페이스, 추상화에도 의존하고, MemoryMemberRepository라는 구현체에도 의존하고 있다.
이를 해결할 수 있는 방법은 DI(Dependency Injection)이다.
DI란, 의존관계 주입 또는 의존성 주입으로 해석되며 필자는 "부품 주입"으로 받아 들인다. (클래스를 만드는데에 필요한 필드의 구현체에 따라 부품이 바뀐다고 생각하기에)
클래스들은 모두 추상화에만 의존할 수 있도록 하고, AppConfig 클래스를 통해 구현체가 담긴 생성자를 리턴하는 방식으로 DI를 진행한다.
이렇게 DI를 해주는 AppConfig를 IoC 컨테이너 / DI 컨테이너 라고 부른다.
IoC(Inversion of Control) 제어의 역전, AppConfig가 모든 흐름을 제어한다.
AppConfig는 객체를 생성하고 객체의 레퍼런스를 생성자를 통해 클라이언트 객체에 전달해주게 된다.
