JAVA 인터페이스와 추상화의 차이점

#JAVA011 #인터페이스 #추상화클래스

Dec 26, 2023

Contents

🍑 개요 🍇 인터페이스와 추상화의 차이점 🥭 추상화와 인터페이스의 공통점 🍋 인터페이스 사용 예시

🍑 개요

인터페이스 (Interface)와 추상화(Abstraction)은 객체 지향 프로그래밍에서 매우 중요한 개념이다. 두 개념의 작동 방식은 동일하나 구현시기와 다중 상속 여부, 그리고 형태 대한 제약이 약간 차이가 있다. 이 둘의 주요 차이점을 먼저 알아보고 좀 더 쉽게 풀어보도록 하겠다.

🍇 인터페이스와 추상화의 차이점

인터페이스

인터페이스는 모든 메서드가 기본적으로 추상 메소드 타입이다. 구현이 없는 메소드이므로 빈 껍데기만 있는 것 처럼 보인다.

다중 상속을 지원한다. 즉 하나의 클래스가 여러 인터페이스를 구현할 수 있다.

일반적으로 다른 클래스가 해야할 일을 강제하지만, 그 일을 어떻게 수행할 지에 대해서는 정의하지 않는다.

추상화 클래스

추상 클래스는 상태(필드)와 메서드(구현포함)을 모두 가질수 있다. 일부 메서드는 구현을 가질 수 있고, 일부는 서브 클래스에서 구현해야 하기도 한다.

추상 클래스는 단일 상속만 지원한다. 하나의 서브 클래스는 오직 하나의 추상 클래스만 상속받을 수 있다.

실제로 개발자로서 일을 하게 된다면, 인터페이스는 발주하는 곳에서 많이 활용하게 되고, 추상화는 반복되는 업무를 효율적으로 관리하기 위해서 많이 사용된다.

인터페이스 적용의 비유

즉, 예를 들어 리모콘 생산을 한다고 가정해보자. 그리고 거기엔 반드시 어떤 리모콘이든지 간에 on/off 기능이 있어야 된다. 이런 경우에 인터페이스의 기능을 생산시점부터 관리 할수 있다.

추상화가 필요할 때

추상화는 객체를 한 두개 만들 때는 그렇기 필요하지 않을 지도 모르지만, 만약 객체를 100~천개를 만들어야 된다고 하면, 각 객체마다 필드값을 설정하기 매우 힘든 단순 반복의 작업이 된다. 그럴때 공통적인 특성을 가진 항목끼리 묶어서 추상화 클래스를 만들어 하위클래스에서 같이 공유하게 만들 수 있게 해주면 된다. 그래서 추상화 작업은 개발자가 일을 하는 도중에 더 효율적으로 관리하기 위해서 작업의 후반에서 종종 만들어지게 된다.

💡

종종 추상화 클래스가 다른 코드들 보다 먼저 명시가 되어있고 구조가 인터페이스랑 비슷하기 때문에, 왜 비슷한 두 개념이 같이 존재 해야되는 지 헷갈리는 경우가 많다. 하지만 이 두 개념은 실제 일을 하는 데 있어서 설계의 목적과 요구 사항에 따라 그 적용 시점에서 큰 차이점이 있다.

🥭 추상화와 인터페이스의 공통점

추상화와 인터페이스는 구조적으로 비슷한 기능을 갖지고 있지만, 객체 지향 프로그래밍에서 주요 공통점이 있다.

이것으로 인해 인간적으로 발생할 오류의 가능성을 획기적으로 낮춘다.

변화하는 요구사항을 원래 코드를 뜯어 고치지 않고, 유지 보수와 확장을 용이하게 해준다.

복잡한 구조를 가진 로직을 구현하지 않아도, 그 기능을 사용 가능하게 해준다.

다형성을 지원하여 그것을 extends나 implements하여서 공통된 특성을 여러 서브 클래스에 동일한 명령으로 각 클래스에 맞는 특성을 가질 수 있게 한다.

중요한 로직을 변경 불가능하게 막으면서도 그 기능을 사용할 수 있게 한다.

여기서 가장 중요한 공통점 확장성과 다형성이다. 이는 코드의 유지 관리를 용이하게 하고, 시스템 확장성을 개선하며 설계의 전반적인 품질을 향상시킨다.

🍋 인터페이스 사용 예시

신입 개발자가 회사에서 일을 하게 된다면, 어려운 로직을 구현하라는 요구보다는 이미 구현된 코드를 재사용하기 위한 상황이 많이 존재한다. 아래 ‘리모콘’에 관한 인터페이스 예제를 살펴보자.

인터페이스 예시코드

이미 구현된 복잡한 인터페이스는 신입 개발자가 마주하지 않을 수도 있다. 하지만 그런 로직을 불러와서 사용해야하는 상황이 많을 것이다. 그런 상황에서 주어진 코드 안에서 어떤 부분이 인터페이스인지 파악 할 수 있어야 된다. 여기서 이를 판단 할 수 있는 구조적 특징을 살펴보자.

첫 번째 특징

예시 코드안에서 InterEx01클래스와 CommonRemocon 클래스의 관계에서 특이한 점을 발견할 수 있다. 그것은 CommonRemocon의 필드값에 객체 Remocon r 이 들어가 있다는 것이다.

두 번째 특징

같은 타입으로 일반적으로 객체를 생성하지만, 다른 타입으로 선언되어 있다. 자식타입의 부모객체를 생성할 수 없다는 것을 감안하면 이는 다형성이 적용되었다는 것을 알 수 있다. 이는 SamsungRemocon 클래스에서 Remocon의 필드값을 가져올 수 있으며 메소드도 오버 라이딩이 가능하다는 것을 바로 파악할 수 있어야 한다.

그리고 아래 CommonRemocon타입의 cr을 선언하는 상황에서 이미 위에서 객체값을 파라메터로 받으므로 (new SamsungRemocon)이 들어가 있는 것을 알 수 있다.

세 번째 특징

CommonRemocon의 생성자에 Remocon타입의 객체를 파라메터로 받아야 되는데, 왜 아래 main메소드 아래에는 new SamsungRemocon이 들어갔는지 의아해 할 수 있다.

이는 다형성이 적용된 관계의 클래스들이 가지는 특징으로 SamsungRemocon이 Remocon과 다형성 관계에 있다는 것을 알수있다. 정확하게 말하자면 Remocon이 부모 타입으로서 이 객체관계로 선언된 모든 자식 타입을 모두 수용할 수 있게 하는 것이다. 이는 객체가 추가될 때 마다 객체 타입을 변경하지 않게 만들어 주는 유용성을 제공한다.

네 번째 특징

CommonRemocon에서 빨간 박스안의 메소드가 구체적인 구현을 하지 않고 호출이 가능하다는 것은, CommonRemocon이 이 메소드를 이미 구현한 구체적인 객체들을 사용하고 있다고 판단 할 수 있다. 이는 인터페이스 또는 추상화 클래스를 참조하고 있음을 알 수 있게 한다.