학부생때나 혹은 책을통해 공부할때
인터페이스를 보고 실제로 쓰게 되는일은 매우 적다.

회사에 들어가도 인터페이스를 사용하지 않는 선임들이 대다수이다.

인터페이스를 쓰지 않는다고 기능구현이 안되는것도 아니고,
쓰자니 번거로울 뿐이다.

그 이유는 왜 써야되는지를 모르기때문.

책에서 나오는 예재들도 너무 단편적이라 코딩에 대한 이해뿐이지, 응용에대한 이해는 하나도 되지않는다.

예를들어 냉장고나 텔레비전 같은 기기를 클래스로 모델링하고
어떤 모델은 A라는 기능이되고, 어떤기능은 B 기능이 된다치자.

책에서는 보통 이런 문제를 상속으로 해결한다.
또는 제품군대로 인터페이스를 뽑아 해결하기도한다.
하지만 상속이나 이런 인터페이스 활용정도로 해결 될 문제일까?

지금 진행하고 있는 프로젝트는 많은 디바이스를 제어해야한다.
각 디바이스는 각각의 클래스로 모델링 되어있고.
디바이스들 끼리는 공통되는 제품군도 있고, 상이한 제품들도 많다.

기기별로 카운팅을 진행해야한다던지, 특정 상태값만 카운팅 해야한다던지
또는, 이러한 일렬의 작업이 필요할때, 그 수많은 클래스들을 어떻게 핸들링 할 것인가.

방법은 간단하다. 기능 하나하나를 인터페이스로 묶고(프로퍼티 한개당 인터페이스 한개)
(절대로 클래스/인터페이스/코드파일이 늘어는걸 두려워하지말자, 코드수가 제한이 있는 플랫폼이 아니라면)

그룹핑이 필요한 인터페이스는 인터페이스들을 모아 그룹으로 묶는다.
행위가 필요한 메서드에서는 각각의 기능별로 캐스팅 여부를 확인하여 작업을 진행하면된다.
차라리 이러한 예제를 보여주는게 더 인터페이스를 응용하기에 적합하다.

그 외에도 인터페이스를 활용할 수 있는 부분은 무한하다.
대부분의 디자인 패턴또한 인터페이스를 활용하면 용이하다.

클래스 상속개념으로도 구현할 수 있는 패턴들이 많지만.

전에 이야기 했듯이, 상속보다는 포함이 낫다.
(상속을 제제하라기보다, 상속을 진정으로 써야하는 경우를 잘 판별해야한다.)

지금 당장이라도 자주사용하는 팩토리 패턴정도라도 인터페이스를 사용하여 코딩해보길 권장한다.
또 인터페이스의 사용이 익숙해짐에따라 public사용을 자제해보도록하자.


1줄요약 : 인터페이스 찬양