[Java] 인터페이스의 용도(usage)에 대해

추상 클래스는 상속을 통해 자식(하위) 클래스에서 설계도를 완성하도록 유도하는 클래스입니다. (= 미완성 설계도)

 

• 추상 클래스는 상속을 위한 클래스이기 때문에 따로 객체를 생성할 수 없습니다.(사실 익명 내부 클래스로 객체 생성은 가능하지만 이는 의도한 바가 아니기 때문에 객체를 생성할 수 없다고 작성하였음)
• 추상 클래스는 메소드에는 'abstarct' 예약어를 사용해서 상속을 통해 '구현' 해야 한다는 것을 알려주고 선언부만 작성하는 '추상 메소드'를 선언할 수 있습니다.

• 자식(하위) 클래스에서는 추상 클래스의 '추상 메소드'를 오버라이딩 및 구현하여 비로소 설계도를 완성시킬 수 있습니다.

abstract class Animal {
    abstract void bark();				// 하위 클래스에서 다르게 동작하는 메소드
    public void sleep() { 				// 하위 클래스에서 동일하게 동작하는 메소드
        System.out.println("Sleeping...zZZ");
    }
}

public class Dog extends Animal{

    private String species;

    public Dog(String species) {
        this.species = species;
    }

    @Override
    public void bark() {
        System.out.println("This puppy barks like " + this.species);
    }

}

 

추상 클래스에 대한 더 자세한 내용은 아래 링크 참조 

[Java] 추상 클래스(abstract class)에 대해

 

자바에는 이 추상 클래스와 매우 비슷한 용도로 사용되는 '인터페이스'라는 것이 존재합니다.

 

추상 클래스는 일부만 완성된 '미완성 설계도'라고 하면, 인터페이스는 '기본 설계도'입니다.

추상 클래스에서는 같은 동작을 하는 메소드에 대해서 abstract 키워드를 사용하지 않고 추상 클래스에 구현했다면, 인터페이스에서는 하나도 빠짐없이 작성되는 모든 메소드가 추상 메소드로 선언되어야 합니다. ( Before JDK 1.8 ver )

 

이어서 인터페이스의 기본 사용법에 대해 알아보겠습니다.

---

인터페이스(interface)

인터페이스란?

인터페이스는 클래스들이 필수로 구현해야 하는 추상 자료형입니다.

추상 클래스와 마찬가지로 인터페이스 또한 내부에는 구현된 코드(메소드나 인스턴스 필드)가 없기 때문에 인터페이스 그 자체로는 인스턴스를 생성할 수 없고, 인터페이스에 대한 구현체를 통해 인스턴스를 생성할 수 있습니다.

 

인터페이스 선언

1. 자바에서 인터페이스를 선언할 때는 'interface' 예약어 사용, 구현체에서는 상속을 'extends'가 아닌  'implements' 예약어를 사용합니다.

public interface Car {
}

public class Suv implements Car{
}

• 단, 인터페이스간의 상속에서는 extends 키워드 사용

 

2. 인터페이스는 인터페이스로부터만 상속받을 수 있고, 클래스와는 달리 다중 상속이 가능

public interface Car extends Navigation, MusicPlayer{

    public static final String name = "자동차";

    abstract void start();
    void stop();
    String ModelName();
}

 

3. 인터페이스에는 구체적인 대상을 생성할 수 없고, 오로지 상수와 추상 메소드만 사용할 수 있습니다. (JDK 1.8 이전)

public interface Car {

    public static final String name = "자동차";
    public static final int wheel = 4;

    default void openWindow() { // After JDK 1.8 ver
        System.out.println("창문 열기");
    }

    static int getWheel() { // After JDK 1.8 ver 
        return wheel;
    }

    abstract void start();
    void stop();
    String ModelName();
}

• JDK 1.8 버전 이전에서는 인터페이스에는 상수(static final)와 추상 메소드(abstract method)만 사용할 수 있었습니다.
• JDK 1.8 버전 이후에는 static 메소드와 default 메소드 사용이 가능하긴 하지만, JDK 1.8 버전 이전 기준으로 통용하겠습니다.
  • default 메소드를 통해 공통적으로 들어갈 기능을 구현할 수 있습니다. 
• 추상 메소드 선언 시 abstract 키워드는 생략할 수 있습니다. ( 컴파일 시 자동으로 생성 )
• 멤버 변수 선언시 public static final 또한 생략 가능 ( 컴파일 시 자동으로 생성 )
  • 인터페이스는 인스턴스가 존재할 수 없기 때문에 상속받은 구현 객체에서 같은 상태를 보장하기 위해서 public static final을 사용합니다.

public class Suv implements Car{

    private String modelName;

    @Override
    public void start() {
        System.out.println("시동이 켜졌습니다.");
    }

    @Override
    public void stop() {
        System.out.println("시동을 끕니다.");
    }

    @Override
    public String ModelName() {
        return name + this.modelName;
    }
}

 

추상 클래스와 인터페이스 비교

공통점

1. 추상 메소드를 가집니다.
2. 그 자체로 인스턴스 생성이 불가능하고 상속/구현한 클래스를 통해 인스턴스를 생성할 수 있습니다.
3. 인터페이스와 추상클래스의 구현, 상속 클래스는 추상 메소드를 반드시 구현하여야 합니다.

 

차이점

1. 추상 클래스는 extends 키워드를 통한 상속, 인터페이스는 implements 키워드를 통한 구현이 이루어집니다.
2. 추상 클래스는 멤버 변수, 생성자, 일반 메소드, 추상 메소드 모두 가질 수 있지만, 인터페이스에서는 상수와 추상 메소드만 가질 수 있고, 생성자와 멤버 변수를 가질 수 없습니다.
3. 추상 클래스는 다중 상속이 불가능 하지만, (태초에 클래스는 다중 상속이 불가능) 인터페이스는 인터페이스끼리 다중 상속이 가능합니다. 
   1. 이 둘은 이 '다중 상속' 여부에 따른 차이가 있지만, 이 기능의 여부로 인해 사용 목적이 갈리는 것은 아님

 

언제 추상클래스를 사용하고 언제 인터페이스를 사용하는가?

추상 클래스는 구현을 통해 하위 클래스에서 공통으로 사용하는 멤버들은 상위 추상 클래스에 메소드로 한 번만 구현함으로써 하위 클래스에서의 불필요한 코드 중복을 방지하도록 의도된 클래스입니다.

• 중복 멤버를 통합하고자 할 때

public class Cat{

    private String type; // 중복 멤버
    private int wakeUpHour; // 중복 멤버

    public Cat(String type) {
        this.type = type;
    }

    public void bark() {
        System.out.println("This Cat howl like " + this.type);
    } // 중복 멤버

    public void sleep() {
        System.out.println("Sleeping..");
    } // 중복 멤버
}

public class Dog {

    private String type; // 중복 멤버
    private int wakeUpHour; // 중복 멤버

    public Dog(String type) {
        this.type = type;
    }

    public void bark() { // 중복 멤버
        System.out.println("This puppy barks like " + this.type);
    }

    public void sleep() {
        System.out.println("Sleeping..");
    } // 중복 멤버

}

위 코드의 Cat과 Dog 클래스는 중복 멤버를 갖고 있습니다. (필드로 보면 type, wakeUppHour, 메소드로 보면 bark(), sleep())

이 때 아래와 같이 중복 멤버를 상위 클래스로 묶고 메소드도 통합하며 추상화를 해주면 나중에 다른 종류의 클래스를 추가, 확장함에 있어 유연하고 구조적인 객체 지향 설계를 만들 수 있게 됩니다.

 

abstract class Animal {

    String type; 
    int wakeUpHour;

    public abstract void bark();

    public void sleep() {
        System.out.println("Sleeping...zZZ");
    }
}

public class Dog extends Animal {

    public Dog(String type) {
        this.type = type;
    }

    public void bark() { // 중복 멤버
        System.out.println("This puppy barks like " + this.type);
    }

}

public class Cat extends Animal{

    public Cat(String type) {
        this.type = type;
    }

    public void bark() {
        System.out.println("This Cat howl like " + this.type);
    } // 중복 멤버
}

• 클래스간 계층 구조를 명확하게 설계할 때 

또한 클래스 끼리 명확한 계층 구조가 필요할 때도 추상 클래스를 사용합니다.

 

이를 테면 리소스의 Owner이거나 또는 권한이 ADMIN인지 검사하는 클래스를 만드려고 합니다. 이 때 어떤 리소스에 대한 검사를 할 것 인지에 작성 하기 전, 추상 클래스에 공통 분모들을 표현(check(), hasAuthority()) 하고, 상속을 통해 여러 Guard 클래스를 확장해나감으로써 상위 Guard 추상 클래스와 하위 클래스 (PostGuard, CommentGuard) 간의 의미있는 연관관계를 구축할 수 있습니다.

// 클라이언트를 검사하는 추상화된 코드
public abstract class Guard { 

    public final boolean check(Long id){ // 로그인 하였고, id에 대한 리소스 권한이 있는지 검사
       return SecurityUtil.isAuthenticated() && hasAuthority(id);
    }

    private boolean hasAuthority(Long id){ // ADMIN이거나, 해당 리소스의 Owner인지 검사
        return SecurityUtil.extractMemberRolesFromContext().contains(RoleType.ADMIN) || isResourceOwner(id);
    }

    abstract protected boolean isResourceOwner(Long id);
}

public class CommentGuard extends Guard {

    private final CommentRepository commentRepository;

    @Override
    protected boolean isResourceOwner(Long id) {
        Comment comment = commentRepository.findById(id).orElseThrow(GuardException::new);
        return comment.getId().equals(id);
    }
}

public class PostGuard extends Guard {

    private final PostRepository postRepository;

    @Override
    protected boolean isResourceOwner(Long id) {
        Post post = postRepository.findById(id).orElseThrow(GuardException::new);
        Long memberId = Long.valueOf(SecurityUtil.getCurrentUserId().orElseThrow(GuardException::new));

        return post.getMember().getId().equals(memberId);
    }
}

 

추상 클래스는 이렇게 밀접하게 관련된 클래스들끼리 코드를 공유할 때 미리 논리적인 클래스 상속 구조를 만들어 놓고 사용이 결정되는 느낌이라면 (상속을 통해 하위 클래스로 자신들의 기능을 확장 시켜가는 느낌, Guard -> PostGuard, CommentGuard)

 

인터페이스는 반대로 관련성이 없지만 같은 성격을 지닌 클래스들끼리 관계를 맺어줄 때, 필요에 따라 자유롭게 붙였다 떼었다하는 느낌으로 볼 수 있습니다. (인터페이스에 정의된 메소드를 각 클래스의 목적에 맞게 기능을 구현하는 느낌)

 

위 상속 관계도가 있다고  가정합시다. 코드로 표현하면 

abstract class Creature {
}

abstract class Plants extends Creature{
}

public class Carrot extends Plants{
}
public class Tree extends Plants{
}
public class Potato extends Plants{
}



abstract class Animal extends Creature{
}

public class Cow extends Animal {
}
public class Pig extends Animal{
}
public class Monkey extends Animal{
}

 

이 때, Eatable 메소드를 Carrot과 Potato, Cow와 Pig 클래스에 추가하려고 합니다.

 

이 메소드를 Creature 추상 클래스에 추가하게 되면, 먹을 수 없는 Tree, Monkey 클래스에도 반드시 추상 메소드를 추가하고 구현해야하는 강제성이 생기게 됩니다. (나무와 원숭이는 먹을 수 없다고 가정 )

abstract class Creature {
public abstract void eatable();
}

abstract class Plants extends Creature{
}

public class Carrot extends Plants{
    @Override
    public void eatable() {
        System.out.println("EAT");
    }
}
public class Tree extends Plants{
    @Override
    public void eatable() {

    }
}
public class Potato extends Plants{
    @Override
    public void eatable() {
        System.out.println("EAT");
    }
}



abstract class Animal extends Creature{
}

public class Cow extends Animal {
    @Override
    public void eatable() {
        System.out.println("EAT");
    }
}
public class Pig extends Animal{
    @Override
    public void eatable() {
        System.out.println("EAT");
    }
}
public class Monkey extends Animal{
    @Override
    public void eatable() {

    }
}

 

메소드를 선언하기만 빈칸으로 놔두면 되기는 하지만, 객체 지향 설계에 위반될 뿐만 아니라 나중에 유지보수 면에서도 좋지 않습니다.

 

따라서 이 때 위 그림과 같이 상속에 얽매이지 않는 인터페이스에 추상 메소드를 선언하고 이를 구현하면서 자유로운 타입 묶음을 통해 추상화를 이룰 수 있습니다.

abstract class Creature {
}

public interface Eatable {
    public void eatable();
}

// Plants
abstract class Plants extends Creature{
}

public class Carrot extends Plants implements Eatable{
    @Override
    public void eatable() {
        System.out.println("EAT CARROT");
    }
}

public class Potato extends Plants implements Eatable{
    @Override
    public void eatable() {
        System.out.println("EAT POTATO");
    }
}

public class Tree extends Plants {
}


// Animal
abstract class Animal extends Creature{
}

public class Cow extends Animal implements Eatable {
    @Override
    public void eatable() {
        System.out.println("EAT COW");
    }
}

public class Pig extends Animal implements Eatable {
    @Override
    public void eatable() {
        System.out.println("EAT PIG");
    }
}

public class Monkey extends Animal{
}

 

이렇게 추상 클래스의 다형성이나 인터페이스의 다형성 모두 클래스의 타입을 통합한다는 의미는 동일합니다만, 언제 어느 상황에 '다형성'을 사용하느냐에 따른 순서 차이로 인해 어느것을 사용하느냐가 갈린다고 볼 수 있습니다.

 

조금 이론적인 느낌도 강합니다만, 많은 코드를 접하면서 깨달아야 와닿을 것 같습니다.

 

<정리>

abstract class를 사용할 때

• 하위 클래스가 오버라이딩 및 재정의 하는 기능들을 공유하기 위한 상속 개념을 사용할 때
• 요구사항과 함께 구현 세부 정보의 일부 기능만 지정했을 때
• 인스턴스 상태를 변경하기 위한 non-final / non-static 메소드가 필요한 경우
• is - A 관계일 때 ("~이다" 의 관계)
• 멤버에 public 이외의 접근자(protected, private)가 사용되는 경우

 

interface를 사용할 때

• 서로 관련성이 없는 클래스끼리 관계를 맺어줄 때 (형제관계, 특정 성질을 가지고 있는 has - A 관계)
• 특정 데이터 타입의 동작을 지정하려고 하지만 해당 동작을 누가 구현하는지 중요하지 않을 경우
• 다중 상속이 필요한 경우 
• has - A 관계일 때 ("~을 가지고 있다")

---

<참고 자료>

 

자바 추상 클래스와 인터페이스의 차이점 이해하기

 

[JAVA] 추상클래스 VS 인터페이스 왜 사용할까? 차이점, 예제로 확인 :: 마이자몽

 

[JAVA] 인터페이스(Interface)의 기본 개념과 Java 8 이후의 변화

 

코딩교육 티씨피스쿨

 

추상클래스와 인터페이스의 차이점