토비의 봄 TV 1회 - 재사용성과 다이나믹 디스패치, 더블 디스패치

(시청일 : 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 클래스 참고