달력

10

« 2018/10 »

  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  •  
  •  
  •  
인터페이스는 참조하는데 사용될 수 있는 타입의 역할을 하는데 이외의 목적으로는 좋지않다.

소위 말하는 상수 인터페이스 등이 있는데 메소드를 갖지 않으며 외부에 제공하는 상수 값을 갖는 static final 필드 만으로.

ex)

interface Sangsu{
static final int A = 2;
static final int B = 3;
static final int C = 10;
}

문제점이 뭐가 있을까.

이 상수를 더 이상 사용할 필요가 없어서 클래스를 변경하더라도 바이너리 호환성 유지를 위해

여전히 인터페이스를 구현해야한다.

이럴 때는 상수 유틸리티 클래스(유형4) 로 구현하는게 좋다.

public class Sangsu{
private Sangsu(){
public static final A = 2;
public static final B = 3;
public satic final C = 10;
}
}

즉 인터페이스는 타입을 정의할 뿐이고 상수를 외부에 제공되기 위한 목적이 아니다.
Posted by 유쾌한순례자

추상클래스로 정의된 타입을 구현하는 클래스는 반드시 추상 클래스의 서브 클래스가 되어야 한다.

인터페이스를 구현하는 클래스의 경우는 인터페이스에 정의된 모든 메소드를 구현하고 인터페이스 구현 계약을 지키면

되므로 클래스 상속계층과는 무관하다.

각각의 장점(?) 즉 외부에 공개된 중요한 인터페이스와 연관시킨 골격 구현 추상클래스를 제공하여 인터페이스와

추상 클래스의 장점을 결합한다.

골격 구현 클래스의 작성법은 다음과 같다.

우선 대상이 되는 인터페이스를 파악하고, 구현할 메소드와 그대로 둘 메소드를 결정한다

그대로 둘 메소드가 골격 구현 클래스의 추상 메소드가 될 것이다.

그다음 그대로 둘 메소드를 제외한 인터페이스의 나머지 모든 메소드를 구현한다.

다음의 예제를 한번 보면 좀 더 이해가 갈 것 같다.

public abstract class AbstractMapEntry<K,V> implements Map.Entry<K,V> {
public abstract K getKey();
public abstract V getValue();

public V setValue(V value){
throw new UnsupportedOperationException();
}

//기타 Map.Entry.equals 메소드에 약속된 보면적 계약은 생략...
}

음 여기 항목도 결론은 상황에 따라 추상 클래스와 인터페이스 중 잘 선택해서 쓰자 라는 것.

추상 클래스는  진화의 용이성 이 중요할 때

인터페이스는 유연성이 중요할 때  인 것 같다.

Posted by 유쾌한순례자