다형성과 추상화, 다형성 보다는 추상화에 대해서 더 집중
캡슐화와 더불어서 객체지향 프로그래밍에 있어 필수적인 것이 추상화
그만큼 매우 중요합니다.
여러 (poly) 모습(morph)을 갖는 것
객체지향에서는 한 객체가 여러 타입을 갖는 것
- 즉 한 객체가 여러 타입의 기능을 제공
iotTimer가 rechageable 인터페이스를 상속하고 있어서, iotTimer는 timer 타입도 되고 recahgeable 타입도 된다.
오른쪽 처럼 iot 객체를 timer, rechargeable type에 할당 할 수 있게 된다.
그럼 다형성 이야기는 왜 나온 것인가 ? -> 추상화 때문이다.
데이터나 프로세스 등을 의미가 비슷한 개념이나 의미 있는 표현으로 정의하는 과정
두 가지 방식의 추상화
- 특정한 성질, 공통 성질(일반화)
간단한 예 (첫번째 방식)
- DB의 USER 테이블 : 아이디, 이름, 이메일
두번째 방식은 서로 다른 구현에 공통된 특징이 있으면 이를 추상화 해볼 수 있다.
위의 세가지 기능이 알고봤더니 푸쉬를 발송하기 위한 구현이었다고 하면, 이를 추상화 하였을 때, 푸쉬 알림 발송으로 추상화 할 수 있다.
이때, 추상화한 타입은 Interface로 많이 표현하고, 추상화한 타입과 구현 클래스를 타입 상속으로 연결을 하게 된다.
추상화 타입은 공통된 성질을 표현하는데, 이 표현은 곧 추상화한 타입이 어떤 기능을 제공하는지 의미 하게 되고, 추상화한 타입 자체는 구현을 제공하지 않는다. (구현이 어떻게 될지 모르니)
실제 구현은 추상화된 타입을 상속하고 있는 클래스(EmailNotifier, KakaoNotifier)에 실제 구현을 제공하고, 구현을 제공하는 클래스를 concrete 클래스라고 한다.
Notifier notifier = getNotifier(...);
notifier.notify(someNoti);
그럼 추상타입을 왜 사용하는가 ? -> 변경이 유연해진다.
기능 요구 추가에 따라서 Cancle 메서드의 코드가 변경된다.
( 주문 취소 처리 로직은 바뀌지 않았는데 ...)
즉 본질하고 전혀 상관없는 다른 부분의 구현 때문에 본질이 바뀌고 있는 것이다.
공통점을 도출하면
- SMS 전송
도출한 추상 타입 사용
사용할 대상 접근도 추상화
Cancle 메서드는 NotifierFactory를 이용하여 Notifier를 구하도록 수정하였다.
통지 방식을 변경해야 한다는 요구사항이 들어와도 DefaultNotifierFactory 부분만 바꿔주면 되겠다.
또는 NotifierFactory의 instance()의 부분을 수정해주면 되겠다.
중요한 점은,
새로운 요구사항이 들어오더라도 주문 Cancle 로직 자체는 변경되지 않는다는 점이다.
이게 바로 추상화를 하는 이유이다