Spring History
- 탄생 배경
- 2000년대 초 EJB(Enterprise Java Beans)의 문제점이 많았음
- 2002년 로드 존슨의 책을 통해 EJB 없이도 고품질의 Application을 만들 수 있다는 것을 보여줌
- 책 출간 후 유겐 휠러, 얀 카로프는 로드 존슨에게 오픈소스 프로젝트 제안
- 유겐 휠러는 지금도 스프링의 핵심 코드를 개발중
- 스프링이라는 이름은 EJB라는 겨울을 넘어 새로운 시작이라는 뜻으로 지음
Spirng 핵심
- Java 언어 기반의 프레임 워크
- 객체 지향 언어의 특징과 잘 맞는 프레임워크
- 고 품질의 객체 지향 Application을 개발할 수 있게 도와주는 프레임워크
- 그러면 객체 지향이란 무엇?
- 특징
- 추상화
- 캡슐화
- 상속
- 다형성(Best!)
- etc..
- 객체 지향 프로그래밍
- 컴퓨터 프로그램을 독립된 단위인 객체들의 모임으로서 파악. 각각의 객체는 서로 협력 가능
- 프로그래밍을 유연하고 변경이 용이하게 개발 가능
Spring 과 객체 지향
- 다형성이 가장 중요!!
- 스프링의 IoC(제어의 역전), DI(의존관계 주입)은 다형성을 활용해서 개발 을 좀 더 편리하게 할 수 있음!
- 다형성이 왜 중요할까?!
- 실세계의 비유. 물론, 객체 지향과 실세계는 1:1로 대응하지는 않음
- 역할과 구현으로 실세계를 구분 가능
- 역할과 구현 ?
- ex) 드라마에서의 배역을 '연예인'이 맡는다. 즉,배역은 역할이고 '연예인'은 그 역할을 구현 함!
- 장점
- 단순, 유연, 변경의 용이
- Client는 대상의 역할만 알면 됨
- Client는 구현 대상의 내부 구조를 몰라도 됨 (역할만 알면 되니)
- Client는 구현 대상의 내부 구조가 변경되어도 영향을 받지 않음 (역할만 알면 되니)
- Client는 구현 대상 자체를 변경해도 영향을 받지 않음 (역할만 알면 되니!!!)
- 역할과 구현을 분리
- 자바 언어의 다형성을 활용 하여 역할은 인터페이스, 구현은 인터페이스를 구현한 클래스로 나눌 수 있음. 오버라이딩, 상속 등으로 실행 시점 구현 부분을 유용하게 변경 가능!
- 객체는 협력 관계: ex)Client 와 Server의 관계
- 한계
- 역할 자체가 변하면, 구현에도 큰 변경이 생길 수 밖에 없음 : ex) 드라마의 배역이 바뀌면...?? 이미 섭외된 배우를 자르고 그 배역에 맞는 배우를 다시 섭외하는 것과 같은..
좋은 객체 지향 설계의 5가지 원칙(SOLID By Robert Martin)
- SRP : 단일 책임 원칙(Single Responsibilty Principle)
- 한 클래스는 하나의 책임만을 가짐.
- 하나의 책임?? 모호하긴 함.. 따라서, 변경이 일어날 때 그로 일어나는 파급 효과가 작으면 SRP를 잘 따랐다고 봄
- OCP : 개방 폐쇄 원칙(Open/Closed Principle)
- 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
- 다형성을 활용해야함 하지만 이에도 문제점은 있음!
- 문제점
- ex) WEB MVC 사용시, SERVICE 부분에서 REPOSITORY 구현 클래스를 직접 선택해야하는 문제(다형성을 활용은 했지만 코드의 변경이 필요하게 됨- 인터페이스에 구현 클래스가 여러개 있으면 객체 생성시 구현 클래스에 따라 변경이 되어야 하니까.. )
- 문제를 어떻게 해결?? 객체를 생성하고, 연관관계를 맺어줘야 함.
- LSP : 리스코프 치환 원칙(Liskov Substitution principle)
- 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
- 즉, 인터페이스의 하위 클래스는 인터페이스의 규약을 따라야 인터페이스를 구현한 구현체를 믿고 사용 가능.
- 컴파일 성공을 넘어 구현이 잘 이뤄졌는지
- ISP : 인터페이스 분리 법칙(Interface segregation principle)
- 특정 클라이언트를 위한 인터페이스를 여러 개 둬야 한다.
- 인터페이스는 명확해 질 것이며, 대체도 용이 해짐
- DIP : 의존관계 역전 원칙(Dependency inversion principle)
- 역할에 의존해야지 구현에 의존하면 안된다는 뜻. 즉,Interface에 의존해야함
- 여기서도 OCP의 문제점에서 처럼 구현 클래스를 직접 선택해 객체 생성 시, 인터페이스와 구현 클래스를 둘 다 의존하는 꼴이 됨!
- 다형성 만으론 OCP,DIP를 지킬 수 없다는 뜻!
- 그럼?!
- 스프링의 DI(Dependency Injection)을 활용 해야함
- 스프링의 필요성!!
- 옛날 EJB를 활용하여 OCP,DIP의 원칙을 지키려면 해야할 일이 굉장히 많았음.. 이를 스프링은 굉장히 편리하게 만들어 주게됨! 따라서?? 스프링은 좋은 객체 지향 프로그래밍을 하려면 뗄래야 뗄 수 없는 관계인 것!
이상으로 블로그 포스팅을 마치겠습니다. 감사합니다 :)
이 글은 인프런 김영한님의 '스프링 핵심 원리 - 기본편'을 수강하고 작성합니다.
출처:https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard
WEB STUDY & etc.. HELLO!