(시청일 : 20190917)
- https://www.youtube.com/watch?v=s-tXAHub6vg : 객체지향의 재사용성과 다이나믹 디스패치, 더블 디스패치에 관한 이야기를 코드를 만들어가면서 설명합니다.
- http://limmmee.tistory.com/28
- https://zetawiki.com/wiki/%EC%A0%9C%EC%96%B4%EC%9D%98_%EC%97%AD%EC%A0%84_IoC
■ 스프링 = Dependency + Injection + Framework
■ Dependency 관계 : Supplier의 변화가 Client에 영향을 주는 경우
- 의존 관계 발생
-> Supplier가 Client의 필드
-> Supplier가 Client 메소드의 파라미터
-> Supplier가 Client의 로컬 변수
-> Supplier로 메시지를 보냄
- 객체지향 설계/개발 : 재사용성이 높다.
- 의존 관계 : Client는 재사용이 어렵고, Client는 컴포넌트/서비스가 될 수 없다.
■ 컴포넌트 : 개발자의 손이 미치지 않는 곳에서도 아무 변경 없이 필요에 따라 확장해서 사용될 수 있는 소프트웨어 덩어리다.
■ 오브젝트 패턴 : 런타임 시에 바뀔 수 있는 (상속 관계보다) 더 동적은 오브젝트 의존 관계를 다룬다.
■ Dependency : (런타임 시에 결정/구성되는 오브젝트의) 의존 관계
- 구현 대신 인터페이스 사용
-> 클래스(구현) 의존 관계 제거
-> 클래스에 대한 의존성은 생성 패턴처럼 3자에게 위임
- 오브젝트 합성(composition) 사용
-> 재사용성을 확보하기 위한 방법 중 한 가지 (상속의 대안)
-> 인터페이스의 사용이 전제 (블랙 박스 재사용)
-> 새롭고 복잡한 기능을 얻기 위해 오브젝트를 조합/합성
-> 런타임 시에 다른 오브젝트에 대한 레퍼런스를 획득
-> 각 클래스가 캡슐화되고 자신의 역할에 충실하게 도와줌
■ Inversion of Control => Container의 역할
- 프레임워크의 동작 방식을 설명하는 용어. 객체지향 컨텍스트.
- 프로그램의 제어 흐름 구조가 뒤바뀌는 것. 모든 제어 권한(실행에 필요한 객체의 생성·사용 등)을 자신이 아닌 다른 대상에게 위임.
- 오브젝트가 자신이 사용할 오브젝트를 스스로 선택/생성하지 않는다.
- 예시
-> 서블릿(기능 정의)-컨테이너(실제 수행)
■ 빈 : 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트
■ 스프링 빈 ; 스프링 컨테이너가 생성, 관계 설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트
■ 빈팩토리/애플리케이션 컨텍스트 : 빈의 생성과 관계 설정 같은 제어를 담당하는 IOC 오브젝트
■ Dispatch
- Static Dispatch => 메소드 오버로딩과 관련 있음.
- Dynamic Dispatch => 컴파일 시간에 reciever parameter(메소드 호출할 시에 사용되는 오브젝트 변수)만 타입 추적 가능
-> Dependency(런타임 시에 결정/구성되는 오브젝트 의존 관계) 가 가능해지게 함.
- Double(Multiple) (Dynamic) Dispatch
-> Visitor 패턴의 근본적인 형태.
-> 컴파일 시간에 reciever parameter(메소드 호출할 시에 사용되는 오브젝트 변수) 뿐만 아니라, 메소드의 파라미터 타입 추적 가능
■ Double Dispatch 예제 코드
public class Dispatch {
interface Post {
void postOn(SNS sns);
}
static class Text implements Post {
public void postOn(SNS sns){
sns.post(this);
}
}
static class Picture implements Post {
public void postOn(SNS sns){
sns.post(this);
}
}
interface SNS {
void post(Text post);
void post(Picture post);
}
static class Facebook implements SNS {
public void post(Text post) { System.out.println("text-facebook"); }
public void post(Picture post) { System.out.println("picture-facebook"); } }
}
static class Twitter implements SNS {
public void post(Text post) { System.out.println("text-twitter"); }
public void post(Picture post) { System.out.println("picture-twitter"); } }
}
static class GooglePlus implements SNS {
public void post(Text post) { System.out.println("text-googlePlus"); }
public void post(Picture post) { System.out.println("picture-googlePlus"); } }
}
public static void main(String[] args){
List<Post> posts = Arrays.asList(new Text(), new Picture());
List<SNS> sns = Arrays.asList(new Facebook(), new Twitter(), new GooglePlus());
posts.forEach(p -> sns.forEach((Sns s) -> p.postOn(s)));
}
}
■ Method Signature (name, parameter types) => 오버라이딩 관계 여부와 관련 있음
- 두 메소드의 return type 및 Method Signature 가 서로 동일 하면, 오버라이딩 관계
■ Method Type (return type, method type parameter, method argument types, exception) => Method Reference 사용 가능 여부와 관련 있음
■ overloading(중복)과 overriding(재정의) 성립 조건
구분 | overloading | overriding |
리턴 타입 | 상관 없음 | 일치 |
메소드 이름 | 일치 | 일치 |
매개변수 타입/개수 | 불일치 | 일치 |
■ Visitor 패턴
- AnnotationVisitor 클래스 참고
'IT > Spring Framework' 카테고리의 다른 글
| 토비의 봄 TV 9회 스프링 리액티브 프로그래밍 (5) 비동기 RestTemplate과 비동기 MVC/Servlet (0) | 2018.02.03 |
|---|---|
| 토비의 봄 TV 2회 - 수퍼 타입 토큰 (0) | 2018.02.03 |
| 토비의 봄 TV 8회 스프링 리액티브 프로그래밍 (4) 자바와 스프링의 비동기 기술 (0) | 2018.02.03 |
| 토비의 봄 TV 7회 스프링 리액티브 프로그래밍 (3) - Reactive Streams - Schedulers (0) | 2018.02.03 |
| 토비의 봄 TV 6회 스프링 리액티브 프로그래밍 (2) - Reactive Streams - Operators (0) | 2018.02.03 |