자바 interface

 

인터페이스를 abstract, final와 함께 대표적인 규제이다.

어떤 객체가 있고 그 객체가 특정한 인터페이스를 사용한다면 그 객체는 반드시 인터페이스의  메소드들을 구현해야 한다. 만약 인터페이스에서 강제하고 있는 메소드를 구현하지 않으면 이 에플리케이션은 컴파일 조차 되지 않는다.

 

사용하는 이유

계산기 기능이 필요한 프로젝트를 진행하는데 시간이 촉박하다. 그래서 계산기 클래스는 개발자 A가 만들고, 개발자 B는 그 클래스를 사용하는 로직을 만들다고 해보자. 이런 경우 개발자 B는 개발자 A가 계산기를 잘 만들어서 나중에 제출할 것이라고 기대하고 개발을 진행할 것이다. 그리고 아래와 같이 가짜 로직을 만들어서 코드를 작성했다.

 

개발자 A가 Calculator를 만드는데 3개월이 필요하다고 한다면 그 시간을 단축하기 위해서 위와 같은 코드를 작성하는 이유가 공감 할 수 있을 것이다. 3개월이 지나고 개발자 A가 Calculator 클래스를 완성해서 인계해줬다. 아래는 그 코드다.

 

 

아뿔싸. 개발자 A는 setOperands의 매개변수를 2개 받고 있지만 개발자 B는 이 메소드가 변수 3개를 받을 것이라고 생각한 것이다. 이건 마치 해저터널의 공사가 중간에서 만나지 않은 것과 같은 상황이다. 이때부터 신경전이 시작된다. 경우에 따라서는 치열하게 다투게 되고 프로젝트는 파국으로 치닫는다. 이러한 문제를 해결하기 위한 가장 좋은 방법은 무엇일까? 협업자 상호간에 구체적인 약속을 하면 된다. 특히 그 약속을 코드 안에서 할 수 있다면 참 좋을 것이다. 그렇다. 인터페이스가 필요한 순간이다.

클래스 Calculator를 사용할 개발자가 이 클래스가 가지고 있어야 할 메소드를 인터페이스로 만들어서 제공하는 것이다. 반대의 경우도 가능하다. 만드는 쪽에서 인터페이스를 제공하면 된다. 양쪽의 개발자는 이 인터페이스를 구현한 클래스 Calculator와 CalculatorDummy를 각각 구현하면 된다.

이렇게 해서 만들어진 코드를 보자. 아래는 약속을 정의하고 있는 인터페이스이다.

 

 

이렇게 클래스가 가지고 있어야 할 메소드를 알려줌으로써 각각 기능을 구현할 수 있게 되었다.

 

 

인터페이스를 참고로 개발자 A가 Calculator 클래스를 완성했다.

 

 

이 사람도 인터페이스를 참고해 CalculatorConsumer를 만들었다. 그럼 CalculatorDummy 였던 가짜클래스를 개발자 A가 구현한 실제 로직인 Calculator로 바꾸면 된다.

 

이렇게 인터페이스를 사용하면 여러명에서 트러블이 없이 더욱 깔끔하게 협업이 가능하다.

약간 인터페이스는 명세서? 틀? 이라고 생각하면 된다.

 

이렇게해서 인터페이스를 이용한 협업에 대해서 알아봤다. 인터페이스를 이용해서 서로가 동일한 메소드를 만들도록 규약을 만들어서 공유한 결과 각자가 상대의 일정이나 구현하는 방식에 덜 영향을 받으면서 에플리케이션을 구축 할 수 있었다.

 

인터페이스의 멤버들은 전부 public이여야 한다.

하나의 클래스는 복수개의 인터페이스를 구현할 수 있다. 자바에서 클래스를 상속할때는 하나의 부모 클래스만 상속 받을 수 있다는 점과는 구별된다

인터페이스도 상속받을 수 있다. 

 

abstract vs interface 
인터페이스와 추상 클래스는 서로 비슷한 듯 다른 기능이다.
abstract는 일반적인 클래스와 다를 빠 없음 abstract 메소드를 하위클래스가 상속 받아서 사용을 강제
실제 구체적인 로직을 가지고 있는 메소드나 필드가 존재할 수 있다.
반대로 interface는 반드시 본체가 없는 메소드들만을 가지고 있어야 한다.

 

 

출처 : opentutorials.org/course/1223/6063