자바 인터페이스를 통한 객체 생성의 장점이 뭘까요

Question

인터페이스와 구현체를 정의하는 이유는 알겠는데...변수 선언 시 굳이 인터페이스를 통해서 구현체 객체를 만드는 이유를 모르겠습니다. 예를 들어List a; if({조건1}) a = new ArrayList<>(); else a = new LinkedList<>();식으로 선언해야 하는 상황이라면 이해가 갑니다.하지만 저런 식으로 사용하는 경우가... 거의 없을 듯 한데...당장 저의 경우만 해도List a = new ArrayList<>(); 처럼 바로 구현체 객체를 지정해서 만듭니다.문제는 List의 메서드가 아닌 ArrayList의 메서드를 사용해야 할 경우, 굳이 형변환을 한 번 더 진행해야 한다는 불편함이 있죠. 주로 전자기기니 붕어빵이니 하며 다형성을 설명하곤 하는데, 그게 각각의 클래스 작성 시의 장점으로는 알겠지만, 변수 선언시에는 오히려 단점이 아닌가 하는 생각이 드네요. 굳이 구현체만의 메서드를 쓰지 않는다는 가정 하에는 대체로 코드가 짧아진다는 장점밖에는 모르곘네요. 질문을 바꾸겠습니다.final List a = new ArrayList();와final ArrayList b = new ArrayList();에서 a가 b보다 좋은 점이 뭔가요?제가 굳이 final로 선언해서 쓰진 않지만, 그냥 변환이 없다는 가정을 위해 추가했습니다.

마사키군 · Accepted Answer

@ 연습용더미1 )성능상의 이슈를 이야기하신 거였군요. 일반적으로 이야기하기로는 "업캐스팅시에는 어느정도 성능의 희생이 있지만, 문제삼을 정도는 되지 않는다" 정도로 퉁치고 지나가긴 하는데, 댓댓글 달린거 보니까 갑자기 궁금해지기도 하고 해서 간단하게 측정해 보았습니다.측정 방법은, Integer를 2천만개 생성해서 담는 List 객체를 생성후 파라미터로 전달해보면서 전체 프로그램 실행 시간을 측정해 보았습니다.실행환경은, IntelliJ에서 작성 후 Zulu OpenJDK 17에서 실행하였습니다. private static final Random randomizer = new Random(); public static void main(String[] args) { LocalTime startTime = LocalTime.now(); ArrayList numericList = new ArrayList<>(); for(int i = 0; i < 20_000_000; i++) { numericList.add(new Integer(randomizer.nextInt(Integer.MAX_VALUE))); printLastEl(numericList); } LocalTime endTime = LocalTime.now(); Duration duration = Duration.between(startTime, endTime); System.out.println("running duration is " + (duration.getNano() / 1000L) + " nano secs"); } static void printLastEl(ArrayList list) { Integer el = list.get(list.size() - 1); //System.out.println("last element is " + el); } 실행 코드는 위 코드구요, 저기서 아래 내용을 바꿔가면서 테스트했습니다.1. 객체타입 (6라인)2. 메서드 파라미터 타입 (19라인)실행될 때마다 현재 시스템의 상태에 따라서 처리 속도에 변동이 있을 것이기 때문에, 5번 실행하고 이 실행시간의 평균을 구했구요, JVM은 한번 실행 후에는 JIT 컴파일러의 실행 최적화에 의해서 점점 다 빨라질 것이라고 추정했기 때문에, 코드를 변경할 때마다 IntelliJ를 완전 종료하고 다시 실행해서 새로 빌드 후 실행했습니다. 실행결과는 다음과 같습니다.(편의상 실행시간은 1000으로 나눠서 표시했고, 평균은 소수점 첫째자리에서 반올림 했습니다) 객체타입 List파라미터 List(이 경우 세부적인 처리는 알 수 없지만, 최소한 최초 생성시에 upcasting이 일어난다고 추정할 수 있겠습니다) 객체타입 ArrayList파라미터 List(이 경우 생성시의 퍼포먼스 저하는 없겠지만, 파라미터 전송시에 upcasting이 일어난다고 추정할 수 있겠습니다) 객체타입 ArrayList파라미터 ArrayList(이 경우에는 upcasting이 전혀 일어나지 않는다고 볼 수 있겠네요) 1회전 963235 2회전 995372 3회전 953858 4회전 16341 5회전 6363 1회전 446188 2회전 188437 3회전 210289 4회전 576457 5회전 962538 1회전 610153 2회전 970036 3회전 1905 4회전 169118 5회전 98443 평균 587034 평균 476782 평균 369931 위 결과를 보면, 객체 타입과 구현체 타입이 동일하지 않을 경우 upcasting이 일어나든 가상 함수 테이블을 사용하든 정확하게는 알 수 없지만, 어쨌건 오버헤드는 어느정도 발생한다고 추정할 수 있겠습니다.하지만 제가 출력한 실행시간이 나노초 단위인데, 1초는 1^9나노초라는 것 같으니, 이정도 오버헤드라면 충분히 감수하고 사용할만한 수준이 아닌가 싶습니다.

붕어빵의계절 · Answer

객체 교환이 용이하죠

Ding · Answer

음.. 인터페이스를 사용하고, 다형성을 도입하는 이유를 다시 찾아보셔야 될 것 같습니다.

연습용더미1 · Answer

&#64;Ding이 답변으로 제가 알 수 있는게 뭔가요? 굳이 글 마지막에다 여기저기 찾아본 티를 냈는데도 굳이 이런 댓글을 다셔야하나요?

마사키군 · Answer

1. 먼저, 하시고 싶으신 이야기는 알겠지만, 본문에 작성하신 &#34;ArrayList의 메서드를 사용할 경우, 굳이 형변환을 한번 더 진행해야 한다는 불편함이 있다&#34;고 하신 부분이 잘 이해가 가지 않습니다. 정확히는 예시가 적절치 못했다는 생각이 드네요. 왜냐하면 ArrayList를 사용하면서 사용하는 메서드들이 모두 List에 정의된 메서드들이거든요(정확히는 List에 정의된 메서드를 ArrayList에서 override). 오버라이드 없이 ArrayList에서 정의된 메서드들의 대부분은 private이거나 실제 개발에서 거의 사용하지 않는 메서드들입니다. 개인적으로는 실무에서 List는 (plain java를 사용한다는 가정하에) 어차피 ArrayList를 거진 100%에 가깝게 사용하기 때문에 굳이 List를 타입으로 써야 하느냐 하는 생각이 있기는 합니다만, 인터페이스를 타입으로 쓰면서 실제 사용만 구현체를 사용하면서 얻을 수 있는 이점이 분명히 있기 때문에, 습관적으로 사용한다고 생각합니다.(다시 한번 언급하는건데, 저는 글쓴이분이 하시고 싶은 얘기가 무엇인지 알 것 같습니다만, List는 그 예시로서 적절하지 못했다고 생각한다는 겁니다) 2. 제 생각에 List의 경우는 그런데요, Map이나 Set은 상황이 좀 다릅니다. Map은 일반적으로 HashMap을 많이 사용하죠. 객체의 hashcode만 잘 구현되어 있다면, 해시테이블을 통해 빠른 속도의 맵을 구현해낼 수 있으니까요.그런데 만약에 이렇게 HashMap을 만들어놓고서, 맵의 데이터를 일부 구간에 해당하는 key만 조회해야 한다고 하면 어떨까요? 내부적으로 데이터가 정렬되어 있다고 한다면, 간단하게 특정 구간에 해당하는 key만 뽑아낼 수 있을 것입니다. 하지만 해시맵은 내부적으로 해시테이블을 쓰기 때문에 자료구조의 특성상 정렬이 지원되지 않고, 결국 데이터가 많으면 많을수록 특정 구간에 속하는 데이터를 조회하는 것이 더 오래 걸릴 것입니다.자바는 이럴때를 상정해서 Map의 구현체로 HashMap이 아닌 TreeMap이 준비되어 있는데요. 내부적으로 데이터 저장시에 이진트리 형태로 저장하게 됩니다. 이진트리라는 자료구조의 특성상, 저장이 되면서 자동으로 정렬되어 저장되게 되죠. 그러면 &#34;데이터를 정렬해서 저장해주는 TreeMap이 더 좋은거 아닌가&#34; 싶을수 있는데, 반대로 TreeMap이 사용하는 이진트리는 데이터를 저장하거나 가져올 때마다 전체 트리를 순회해야 하기 때문에, 데이터가 많아질수록 put이나 get할때의 속도가 느려집니다. 역할에 따른 Trade-off가 있는 것이지요.대부분의 경우에는 처음에 key/value 타입의 데이터 저장시에 HashMap을 사용할 것입니다. 넣고 빼는 속도가 빠르기 때문에, 가장 일반적으로 사용할 수 있는 구현체이니까요. 그리고 이 HashMap을 각 객체의 메서드로 전달하면서 필요한 로직을 처리하고, 그 처리를 위해 HashMap을 사용할 것입니다.그런데 어느날, 제가 위에서 언급한 요구사항-특정 구간에 해당하는 key값에 해당하는 value값만 가져와서 처리-을 처리해야 할 일이 있을수도 있을텐데요. 이러면 전체 프로그램의 구성이나 요구사항의 내용 등을 살펴서, trade-off를 따져서 HashMap을 그대로 사용하고 후처리를 하거나, TreeMap을 사용해서 더 빠르게 처리한다는 선택지가 있을 것입니다.- 넣고 빼는 작업이 많고, 구간 조회하는 부분이 더 적게 실행된다고 판단되면 HashMap을 쓸 것이고 - 긴 시간동안 프로그램이 계속 구동되면서 천천히 Map에 데이터를 쌓아오다가, 어느순간 거대해진 Map 덩어리를 통해서 구간 조회를 해야 한다면 TreeMap을 쓰겠죠.여기서 만약에 2번을 선택하게 된다면, HashMap을 파라미터로 받는 모든 메서드들의 파라미터 타입을 TreeMap으로 고쳐야 할 것입니다. 반대로, 그렇게 TreeMap으로 사용해오다가, 요구사항 추가에 의해서 로직은 그대로지만 프로그램의 사용 패턴이 변경되어, 다시 HashMap을 쓰는게 유용한 시기가 오면 또 전체 메서드들의 파라미터 타입을 수정해야 할 것입니다.어차피 TreeMap이나 HashMap이나 key/value 형태로 데이터를 저장한다는 본질은 동일한데(여기서 본질이 동일하다는건, 클래스를 사용하는 개발자의 입장에서 사용방법이 동일하다는걸 의미합니다. 결국 개발자는 어떤 형태로던지 key/value 형태의 데이터를 넣고 조회하려고 들겠죠), 그냥 TreeMap을 쓰건 HashMap을 쓰건 받는 쪽에서는 어떤 통일된 구성을 통해서, 위에서 언급한 동일한 본질에만 접근할 수 있으면 좋을 것입니다. 이거를 OOP에서는 &#34;구현측(구현측이라고는 하지만, 정확히는 HashMap이나 TreeMap을 만들어서 데이터를 넣어주는 코드)에서만 어떤 식으로 저장하는지 알면 되지, 만들어진 Map을 가져다 쓰는 쪽에서는 저장방법을 알 필요가 없이 동일한 처리를 할 수 있으면 되겠구나&#34;라는 가정 하에 Map이라는 인터페이스를 사용합니다. 어차피 Map 인터페이스에는 get이니 put이니 메서드가 다 정의되어 있고, 가져다쓰는 쪽에서는 구현 방법에 상관없이 get/put 메서드를 사용하기만 하면 되니까요.(구구절절하게 작성했는데, 납득하셨을지 모르겠습니다. 어렵게 적은거 같기는 한데, 제 실제 사례입니다 ㅠ_ㅠ 그때는 Map이 아니라 Set이라는 차이가 있지만... 그때 이걸 잘 몰라서, HashSet 파라미터를 죄다 Set으로 갈아치우는 생고생을 했습죠; 하지만 어차피 실무에서 Set은 잘 안쓰는거 같고, Set에도 마찬가지로 HashSet / TreeSet 있기 떄문에, 편의상 Map으로 고쳐서 언급했습니다)3. 만들어진 프로그램은 언제 어떻게 요구사항이 바뀔지 알 수가 없습니다. 위에서 언급한 TreeMap/HashMap 요구사항과 마찬가지로, 일단 관례적으로 ArrayList를 사용해서 로직을 개발해뒀다가, 어느순간 갑자기 필요에 의해서 LinkedList를 사용하는게 훨씬 적절한 요구사항이 들어올 수 있습니다. 처음에는 &#34;설마 ArrayList에서 바뀌겠어&#34; 싶었던게, 시간이 흐르면서 상황이 바뀔 수 있다는 것이지요. 정말로 이런 상황이 왔다면 LinkedList를 사용하기 위해서 이 ArrayList를 받는 모든 파라미터를 LinkedList 타입으로 바꿔야 합니다. 프로그램의 규모가 커지면, 수정하는 부분이 많아지면 많아질수록, 리스크가 점점 더 커지죠. 설령 오류가 발생할 가능성이 한없이 0%에 수렴하는 수정내용이라 하더라도요.이 리스크를 짊어지지 않기 위해서, 아예 처음부터 데이터를 주고받을때는 List 인터페이스 타입으로만 주고 받는 것이고, List 인터페이스 타입에 정의된 메서드만 사용하는 것입니다. 실제로 자바의 컬렉션 인터페이스들은 꽤 구성이 잘 되어있는 편이라서, 굳이 구현체 클래스의 자체 메서드를 사용할 일이 없습니다. 저도 ArrayList에서 선언된 메서드는 한번도 사용해본 적이 없구요.4. 자바의 인터페이스는 그 자체로 굉장히 복잡하고 어려운 주제라고 생각합니다. 그래서 단순히 &#34;메서드를 정의만 해두고, 구현체에서 상속받아 구현하도록 강제하는 형태&#34;라고만 인지하고 있으면 이게 무슨 의미가 있는가 하는 생각이 들 수 있지만, 공부하면 공부할수록(특히 OOP에 대한 지식이 쌓여가고 OOP적으로 사고하는 능력이 늘어날수록) 놀라움을 느끼게 하는게 자바의 인터페이스라는 요소라고 생각합니다. 이미 여러군데서 찾아보셨을 것이라고 생각하지만, 인터페이스 그 자체가 아닌 자바라는 언어의 OOP 구현, 그리고 그 중에서도 특히 추상화나 규약 등에 대해서 공부해보시는 것을 추천드립니다.

연습용더미1 · Answer

&#64;마사키군일단 장문의 답변에 감사드립니다.제가 굳이 List와 ArrayList 예시를 든 이유는, 제가 다니는 회사 레거시 코드(무려 자바 1.5)에서 ArrayList.trimToSize() 라는 메서드를 봐서 그렇습니다.실질적으로 사용할 필요가 없는 코드인데 굳이 있길래 저도 따라서 쓰긴 합니다만, 이게 인터페이스 선언이 익숙해서 그런지 자꾸 그냥 List를 선언해서 나중에 컴파일 오류가 뜨더라고요.차피 고대 유물급 레거시고 코드 목적 자체도 통계 위주라 ArrayList밖에 쓸 일이 없어서 예시를 저렇게 들었습니다만... 제가 질문을 잘못했네요. 제가 알고싶었던건 '성능적 문제'였는데, 답변자분의 답이나 다른 인터넷들의 글이나 다 비슷하게 개발, 수정 부분의 얘기고 성능적인 부분에 대한 말이 없는 것을 보면 성능적인 차이는 없다고 보는게 맞나봅니다.

연습용더미1 · Answer

&#64;마사키군 와... 감사합니다.안그래도 ArrayList랑 LinkedList 성능 비교 업무시간에 몰래 해보다가 더 시간을 할애하긴 위험해서 질문했던건데 직접 해주시다니... 이런 상황에서 성능 비교 글은 아직 없는 듯 한데 Tech 게시판에 그대로 올리셔도 좋을거같네요.

자바 인터페이스를 통한 객체 생성의 장점이 뭘까요

7개의 답변

#interface 목록