interface 를 왜 사용하는가

자바를 처음 접한 건 아마 2001년인 것 같다.

그 때는 이것저것 관심이 많아서 온 갖 거를 들쑤시고 다녔는데

java 도 그 중에 하나였던듯

어렴풋한 기억에 그 때 jdk1.2 였나.. 1.4였나 그 정도 버젼을 썼던 것 같다

 

java 에 가장 실망한 거는

독립 배포가 불가능하다는 거였는데

배포하려면 jre도 함께 배포해야 한다는

크나큰 단점 때문에 공부를 좀 하다가 말았던 것 같다

 

그러다가 군대 갔을 때 짬먹으니깐 너무 심심해서 코딩 좀 하고 싶었는데

그 때 부실한 인트라넷 환경에서

겨우 구한 컴파일러가 JDK 였다.

그걸로 이것저것 했던 기억이 난다.

 

한번은 망고메신저라는 걸 만들었었는데

당시 군대에는 맨날 컴퓨터 만지는 행정병이라도 메신저가 없어서 영 불편한 게 아니었다

옆 사무실 애들한테 밥 먹으러 가자고 찾아가야 하고 잡담도 못하고 말야.

그래서 만든게 망고메신저..

난 망고다 이런게 아니고 사무자동화를 통해 망고가 되자

뭐 이런 걸 표방한 것이었다 --;;

 

후임들한테 보채서 반강제로 jre깔게하고 java 실행하는 거 배치파일로 만들어서 깔게하고

채팅 테스트를 하는데...

아나 다 좋은데

대화창 스크롤바가 계속 가장 아래로 내려가서 가장 마지막에 한 대화가 보여야 하는데

그게 안되고 스크롤바가 계속 원래 있던 위치에만 있었음.

즉 대화를 입력할 때 마다 손으로 스크롤바를 내려줘야 한다는 -_-;;

api 찾아가면서 별 짓을 다했는데도 안되서 포기.

그 이후 전산보안감사에 걸려가지고 -_- 폐기되었다 ㅋㅋㅋ

 

 

 

잡설이 길었고

이 java 라고 하는 걸 공부하면서 가장 혼란스러웠던게

바로 interface 가 뭐냐 였다.

그래서 참고용으로 잠깐 노트를 둔다. 정확하지 않을수도 있다.

 

 

일단 상속에 대해서 생각해보자

상속은 엄마 클래스가 갖고 있는 field와 method 를 자식 클래스가 가져오는 것이다.

예를 들어

금융상품 이란 엄마클래스가 있으면

이걸 상속받은 자식클래스들은 주식상품, 펀드상품, 채권상품 클래스가 있을 수 있다는거지.

금융상품 이란 클래스에는 공통적인 상품의 field와 method 를 모아 놓고

자식클래스에는 각 상품별로만 필요한 field 와 method 만 넣어놓는거다.

 

이렇게 하면 확실히 하나의 클래스에 모든 field 를 모아 놓는 것 보다 메모리를 효율적으로 사용할 수 있고

새로운 상품이 나오거나 특정 상품에 대한 변경이 있을 시 유지보수가 깔끔하다.

그래서 상속이라는 거를 쓰는거다.

단점은 design 이 어렵다. 확실히 현업에서는 이런 경우 공통된 field 와 method 를 정립하는 게

꽤나 어려운 일이다. 이게 공통부인지 개별부인지 헤깔리는 것도 많고 말야.

여기까지가 기본적인 상속.

(중간저장)

 

근데 금융상품에 매도 라는 method 가 있다고 치자.

상품 잔고를 줄이고 해당하는 금액만큼 돈이 인출되는 것임.

근데 자식 중에 펀드상품은 세금계산하는 부분이 복잡하고 다른 상품들이랑은 다르네.

이런 경우 펀드상품은 매도method 를 재작성한다.

이런 걸 overriding 이라고 한다.

overriding 을 통하면 공통method 를 사용하고 싶은 상품들은 별도로 그 method 를 구현할 필요가 없고

별도 method 가 필요한 class 는 구현하면 된다.

 

 

자 이젠 금융서비스를 만들어보자

input 으로는 계좌안의 상품 중에 어떤 ? 상품이 들어오고

output 은 상품의 평가금액이라고 한다.

문제는 input 에 어떤 상품이 들어올지 모른다는 것인데

그렇기 때문에 각 상품별로 서비스를 각각 만들어야 하는것인가?

그건 너무 비효율적이다.

그래서 그런 경우 엄마 클래스인 금융상품 클래스 타입으로 input 을 받으면 된다

 

즉 다시 말하면 엄마클래스의 인스턴스는 자식클래스의 인스턴스를 담을 수 있다.

예) 금융상품 a = new 주식상품();

대신 a 는 금융상품의 field 와 method 에만 접근이 가능하다.

그리고 주식상품에 평가금액() 라는 메소드가 금융상품 평가금액() 라는 메소드를 overriding 한 경우

예) a.평가금액(); 를 하는 경우

금융상품.평가금액() 가 아닌 주식상품의 평가금액() 가 호출된다.

 

즉, 각 특정상품별로 평가금액() 이 모두 overriding 되어 있다고 한다면

요청된 서비스는 다음과 같이 구성될 수 있겠다

 

금액 평가금액내놔(금융상품 a){

  return a.평가금액();

}

 

 

자 근데,, 금융상품 클래스에는 평가금액 구하는 방법을 구현해놓기가 애매하고

자식클래스들에게 평가금액 구하는 방법을 다 구현하라고 시키고 싶어.

이런 경우 엄마클래스인 금융상품 클래스를 abstract 로 선언을한다.

그리고 평가금액 method 도 abstract 로 선언하여 포함시키고 구현은 하지 않는다.

이런 경우 모든 자식 클래스들은 평가금액 method 를 overriding 해야 하는 의무가 있다.

대신 이제는 엄마클래스로는 instance를 생성할 수 없다는 것.

 

자 여기까지 오면 상속은 반쯤 희석화된다는 느낌이 온다.

그리고 interface 가 등장한다.

interface 는 상속에서 엄마 클래스라고 보면 되는데

모든 메소드를 자식 클래스에게 구현하라고 시키는 것이다. 모조건 의무적으로 말이지.

그래서 자식클래스 애기들은 interface를 상속extends 하는 것이 아니라

implements구현한다.

 

이제 interface 는 껍데기가 되는 것이고 말그래도 interface 역할만 하는 매개체 같은 놈,

여러 클래스의 인스턴스를 담을 수 있는 그릇 같은 것이 된다

모든 구현부는 이 interface 를 구현하는 구현class 들에게 맡긴 채 말야.

 

이런  경우 해당 interface 를 구현하는 class 들의 spec 은 표준화 되기 때문에

하나의 interface 객체로 여러 class 의 메소드를 호출할 수 있다.

상속은 준다는 의미가 강한데 비해 그런 의미는 희석화 되고 부담만을 지우는 interface

뭐랄까 polymorphism 의 극대화 같다는 느낌이 든다.

 

이 interface 는 표준화된 관리가 필요한 enterprise 영역에서

EJB 등의 형태로 많이 사용되고 있다.

http://raweater.blog.me/20108834608

[출처] java | interface 를 왜 사용하는가|작성자 raweater  

[출처] java | interface 를 왜 사용하는가|작성자 raweater