스프링
스프링 탄생 비화
EJB 이론이 좋으면 뭘하니 .. 지옥불인데 ㅜ
이를 싫어한 천재 개발자들이 내가 만들어도 저것보다 낫다는 말과 함께
이 구성으로 개발기획
역사
로드 존슨의 예제 코드를 보고 매력을 느낀 유겐 휠러와 얀 카로프 가 오픈소스 프로젝트를 제안하여 현재의 스프링 개발
스프링
선택기술들은 그와 관련된 기술을 좀 더 편리하게 사용할 수 있도록 도와주는 것.
스프링 프레임워크
스프링 부트
스프링 부트는 스프링 프레임워크를 더 편하게 사용할 수 있도록 하는 것 !
_스프링은 자바 언어 기반의 프레임 워크로 객체 지향을 효율적으로 좋은 애플리케이션을 개발할 수 있게 도와주는 프레임워크이다 !!
객체 지향 프로그래밍
객체지향 -> 추상화, 캡슐화, 상속, 다형성의 특징 + 객체들의 모임으로 명령어를 파악하면서 유연하고 변경에 용이함.(하나만 바꾸면 다 적용)
다형성
역할과 구현을 분리하여 변경을 편리하게 한다.
클라이언트는
-> 인터페이스만 알면 된다.
-> 내부구조를 몰라도 된다.
-> 내부구조가 변경되어도 영향을 받지 않는다.
-> 구현 대상을 변경해도 영향을 받지 않는다.
=> 객체를 설계할 때 역할과 구현을 명확하게 분리 !!
=> 확장 가능한 설계
이에 따른 한계 .... -> 인터페이스 자체가 변하면 큰 변경이 발생 / 역할과 대본 자체가 변경되어야 한다면 ,,,, + 인터페이스의 안정적 설계가 매우 중요...
SOLID
• SRP: 단일 책임 원칙(single responsibility principle)
-> 한 클래스는 하나의 책임만 가져야 한다. ( 변경이 있을 때 파급 효과가 적음 )
• OCP: 개방-폐쇄 원칙 (Open/closed principle)
-> 소프트웨어 요소는 확장에는 오픈이나 변경에는 클로즈 ( 다형성 활용 )
-> 구현 객체를 변경하려면 클라이언트 코드 변경 필요,, / 다형성을 활용해도 OCP 원칙 만족 불가
• LSP: 리스코프 치환 원칙 (Liskov substitution principle)
-> 객체는 프로그램의 정확성을 건들지 않으면서 하위의 인스턴스로 변경 가능해야 한다. ( 규약 지키기 )
• ISP: 인터페이스 분리 원칙 (Interface segregation principle)
-> 특정 목적 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다. ( 명확성 상승, 대체 가능성 상승 )
• DIP: 의존관계 역전 원칙 (Dependency inversion principle)
-> 구체화 말고 추상화에 의존해야 한다. ( 역할에 의존하라. but DIP 위반 )
=> 객체 지향의 핵심은 다형성이나 다형성 만드로는 OCP, DIP를 만족할 수 없음 .. 무언가가 더 필요하다 !
객체 지향 설계와 스프링
DI 컨테이너
스프링 ??? -> 위에서 OCP, DIP 만족 불가능을 가능으로 만들어 주는 기술이 사용된다 !! 이것이 의존관계, 의존성 주입 = DI(Dependency Injection)
모든 설계에 역할과 구현을 분리하여 개발하자.
// 추상화라는 비용과 확장을 유념해서 개발하도록 !
