박근혜
4k
2016-03-03 23:51:04
23
22132

인터페이스 왜 쓰는지 아세요?


Java interface .를 왜 쓰는지 정확히 알고 계신가요?


아님 그냥 Service, Dao 인터페이스 처럼 그냥 패턴으로 알고 쓰는건가요?


제가 보기엔 후자가 압도적으로 많아 보이더라고요..


Class로만 만들도록 설계하지 말고 Interface 구현을 통해 공통으로 구현 가능 하도록 한번 해보세요




0
4
  • 댓글 23

  • 손이시렵다
    1k
    2016-03-03 23:54:06

    저는 OCP 때문이라고 생각하는데 이걸 아주 명쾌하게 설명까지는 못하겠네요

    0
  • 그땐그랬지
    333
    2016-03-04 00:20:05

    후자가 많아 보일수도 있겠으나 그게 정답은 아니죠

    객체지향 언어(자바, C# 등)는 코딩을 객체지향적으로 개발 하는게 중요합니다.

    객체지향적으로 코딩 하지않아도 프로그램 개발하는데 문제는 없습니다.

    프로그램 개발이 끝나고 유지보수 또는 프로그램이 확장된다면

    좀더 변화에 유연하게 대응할 수 있게 하기 위함이죠

    이거 고치면 저거 안돌아가고 다른 거 고치려면 첨부터 다시 짜는게 낫다는 둥 이런말을 안듣도록 짜려는

    노력이 필요한것이죠 

    인터페이스로 짜면 객체간의 결합이 느슨해 집니다.  컨트롤러가 인터페이스를 통해 인터페이스 구현체

    와 연결하면 이후 다른 인터페이스 구현체로 변경이나 확장이 용이합니다.

    컨트롤러 수정없이 인터페이스 구현체만 갈아끼듯 적용하면 되거든요

    더 많은 장점이 존재하지만 얘기가 길어지네요...










    0
  • 영호충
    78
    2016-03-04 04:17:13

    c++ 로 com 개발을 해본 사람에게는 매우 쉬운 이야기이죠..

    0
  • fender
    17k
    2016-03-04 07:28:28

    아마도 인터페이스의 유용함을 체감하지 못한다면 객체지향 패러다임으로 설계하는 습관이 들지 않으셨을 가능성이 높습니다.

    실제로 우리나라 SI에서 흔히 적용하는 데이터 중심적 설계에선 유일하게 볼 수 있는 인터페이스가 스프링의 AOP를 돕기위한 서비스들에 의미없이 붙이는 것이 전부이니 그런 생각이 들 수 있습니다.

    제 경우는 다행히 처음부터 객체지향적인 방식으로 접근하는 방법을 배우게되서 항상 모든 설계의 출발은 인터페이스부터 시작하는 방식으로 개발하고 있습니다. 그러다 보니 반대로 자바 스크립트 같이 인터페이스가 없는 언어에는 적응하기 어려운 문제가 있더군요.

    여담이지만 인터페이스는 의사 코드(pseudo code)를 통한 모델링에도 매우 유용합니다. 전 경력이 얼마 없었을 때는 괜히 멋있어 보여서 UML 다이어그램을 그리고 이런 저런 문서를 만드는 방식으로 설계를 했는데 나중에는 그 것이 문서를 위한 문서라는 것을 깨닫게 되어 요즘에는 의사소통을 위해 꼭 필요한 경우가 아니면 설계는 그냥 의사 코드를 이용해서 하고 있습니다.

    객체지향적으로 설계를 하면 가장 먼저 떠오르는 생각은 항상 이 시스템에는 어떤 유형(type)들이 있을까 입니다. 그 다음에 그런 유형들 간의 관계를 고민하고, 그리고 각 유형의 동작과 속성에 대해 고민하게 됩니다.

    그래서 유형이 떠오르면 바로 그 이름으로 비어있는 인터페이스를 만들고, 관계를 고민하면서 필요하면 인터페이스를 상속으로 이어주고, 그 다음에 각 유형의 API 수준의 속성이나 메서드의 시그네쳐만 추가합니다.

    그리고 최종적으로 인터페이스보단 추상 클래스나 일반 클래스가 어울리는 유형(예컨대 도메인 객체나 VO)들만 적절하게 전환해주면 완전한 API 수준의 설계가 완료됩니다.

    이제 남은 작업은 전환 이후에도 남아있는 인터페이스를 실제 구현하는 일입니다.

    반면에, ERD부터 그리고 테이블과 1:1로 매칭되는 VO를 기계적으로 만든 다음에 기존 MVC 컨트롤러 소스를 복사 붙여넣기 해서 화면에 맞게 조금씩 수정하는 방식은 전혀 객체지향적인 접근 방법이 아닙니다.

    객체지향을 사용하고 있지 않다면 객체지향의 핵심 개념인 인터페이스의 유용성을 느끼지 못하는 것이 무리는 아니라고 생각합니다.

    어쩌다가 불가피하게 그런 데이터베이스 중심적인 접근을 하게 되는 건 몰라도 마치 그런 방식이 표준인 것처럼 학원에서 가르치고 실무에서 템플릿처럼 쓰이는 건, 개인적으로는 정말 무언가 단단하게 잘못되었다고 생각합니다.

    6
  • 블랙홀
    220
    2016-03-04 10:06:45
    서블릿 API를 보시면 거의 대부분 Interface로 되어 있습니다. 왜 그렇게 만들었는지 고민해보시면 interface를 왜 사용해야하는지 알수 있을것 같네요.


    0
  • yamanin
    2k
    2016-03-04 10:16:05

    추상화, 다형성 솔찍히 단어는 잘모르겠고,

    음. 프로그램의 관계를 먼저 정리하기 위해서 사용한다. 라고 할수 있있을꺼 같아요.


    예를 들어서 길이 있는데... A,B,C라는 길을 순차적으로 가야 되요.

    A->B->C 이렇게 이동하는거죠. 

    어떤방법으로 갈지는 나중에 정하면 되요.

    A->B로는 버스로 B->C로는 걸어서 이렇게 구현을 하는거죠.


    뭐 구현을 하다가 보니까. B->C로 이동하는 곳에 마을버스가 생겼어요.

    B->C로 이동하는 방법을 바꾸면되요.


    더 어렵나.ㅠㅠ;;;

    1
  • 시소당
    270
    2016-03-04 13:33:22

    지금 java가 대부분 웹에서만 주로 쓰여서

    인터페이스 개념이 퇴화된거 같네요


    인터페이스를 쓰는 이유는 협업에서 어떤 일관성있는 작업이 있을때 여러명이 작업을 한다고 하면


    어떤 글을 쓰는 행위가 어떤패턴으로 이루어져 있고

    다른 성격의 글을쓰는 행위도

    이전글을 쓰는 패턴이랑 동일한 형태로 구성이 되어있어서 여러명이서 동시에 동일한 구현을 하기위해 인터페이스를 이용하는데 주로 쓰입니다


    하지만 웹에선 거의 의미가 없는데 무분별하게 쓰이는거 같습니다

    자바 어플리케이션에서는 유용한 부분이 있는거 같네요


    https://wikidocs.net/217

    인터페이스를 이해하는데 도움이 되는 글 같네요


    1
  • 삼식이
    1k
    2016-03-04 13:46:20

    그냥 닉네임이 개짜증남

    4
  • 지붕뚫고높이차
    808
    2016-03-04 15:27:54

    인터페이스는

    생명주기가 같은  2개 이상의 모듈을

    수정의 비용을 감수 하더라도

    교체의 비용을 줄이기 위해 사용합니다.


    수정요구가 많고 모듈의 교체 이슈가 없는

    업무에서는 

    절대로 사용하지 말아야 합니다.


    많은 분들이 오해하시는건

    교체라는건 새로운 모듈도 사용하고

    기존 모듈도 폐기가 아닌 사용을 한다는 겁니다.

    윗분 링크에 있는 예제에서도

    곰이 사자로 교체된다고 곰이 죽는건 아니었잖아요.  ^^


    인터페이스를 통해 결합도가 낮아진다는 의미는

    교체에 대한 비용을 의미하는 것이고

    모듈 속성의 추가 수정 삭제 비용은 그만큼 

    감수해야 한다는 의미입니다.


    다들 경험하고 계시잖아요.

    메소드 추가하면

    인터피이스와 구현 클래스 둘다 수정해야 하고

    코드 탐색하면

    빈 껍데기만 있어 유지보수도 어렵구요.


    또한 많은 분들이 jdbc 서블릿 등의 예를 들어

    인터페이스를 써야한다고 이야기 하시는데


    jdbc 기능이 추가되 인터페이스 메소드 1개가 정의됬다고 가정해 봅시다.

    여러분이 실제 업무에 활용하려면

    1년이 될지 2년이 될지 모르는 겁니다.

    그만큼 개발비용이나 배포 비용이 크다는 겁니다.

    실 예로 아직까지

    20세기에 만들어진 jdbc 드라이버를 쓰는 환경도 봤습니다.


    다시한번 이야기 하면

    인터페이스의 필요성에 대해 다들 좋은 의견을

    이야기 하셨는데


    수정이 아닌 교체비용을 줄이기 위해 사용합니다.

    그게 아니라면 사용하지 마세요.



    -1
  • 지붕뚫고높이차
    808
    2016-03-04 15:42:19

    경험상 인터페이스는 

    현상을 파악한뒤 

    리펙토링을 통해 인터페이스를 쉽게 확보하는게

    효율적이었습니다.


    특정 클래스에 기능을 집중할때는

    abstract class 를 사용하고

    기능이 분산되어 있을때는

    여러개의 interface 로 유연하게 코드를 만들었습니다.

    혹시나 이야기 드리는데

    업무 경험에 따라

    인터페이스를 바로 도입하기도 했으니

    오해하지 말아주세요.


    인터페이스(추상화)는 객체지향 언어에서 꼭 필요한 개념입니다.

    단 목적에 맞게 잘 써야 한다는  조건이 붙구요.




    0
  • 시소당
    270
    2016-03-04 15:48:40

    5년전에도 다들 웹플젝에선 인터페이스를 싫어했군요 


    http://okky.kr/article/161248

    0
  • 개발새발1
    386
    2016-03-04 17:21:42


    // 결제 인터페이스
    public  interface Pay {
    
    	public void payment ();
    }
    
    // 카드결제 클래스
    public  class CardPay implements Pay {
    
    	public void payment () {
    		// 카드결제
    	}
    }
    
    // 현금결제 클래스
    public  class CashPay implements Pay {
    
    	public void payment () {
    		// 현금결제
    	}
    }
    
    // 결제 프로세스 컨트롤러
    public  class PaymentController {
    
    	public void process () {
    		Pay pay = null;
    
    		if (카드결제) {
    			payment = new CardPay();
    		} else if (현금결제) {
    			payment = new CashPay();
    		}
    
    		/* 이후 기타 결제방식을 추가해도 유연한 대처 가능 */
    
    
    		pay.payment();
    	}
    }
    

    이런 이유 때문이 아닐까요?

    0
  • 시소당
    270
    2016-03-04 17:37:00

    음 개발새발1 님이 구현한 것은 interface 를 쓴 이유가 유연하게 대처하기 위해 한 것이 아니고

    payment라는 메소드명을 강제하기 위해 쓴거 같네요 


    다른 메소드를 쓴다면 문제가 발생하니 interface 로 강제성을 둔거죠

    만약 유연하게로만의 의미가 있다면 같은 메소드명으로만 구현했다면 같은 결과를 얻을 수가 있습니다


    그래서 interface로 메소드명을 강제한 후 설계를 하여 다른 메소드를 못쓰게 막는 효과를 얻는거구요


    근데 그런 강제성이 협업에서 효과를 잘 볼수 있죠


    지금 현재 웹 플젝의 문제가 저런의도없이 모든 페이지에 저런 interface implement를 쓴다는게 문제라고 지적한 거에요


    핵심은 객체에 상관없이 payment라는걸 호출하면 같은 기능을 수행하게 되게 설계를 하고 싶어서 interface로 강제성을 부여하는 거라고 볼수 있을듯 합니다

    0
  • fender
    17k
    2016-03-04 19:16:12

    인터페이스를 사용하면 구현체를 다른 것으로 대체하기 쉽다는 것은 인터페이스를 활용했을 때 얻을 수 있는 장점 중 하나일 뿐, 그 것이 인터페이스가 존재하는 유일한 의미는 아닙니다.

    하다못해 'java.io.Serializable' 같은 마커 인터페이스만 생각해봐도 이 점은 명확하리라 생각합니다.

    언어를 막론하고, 프로그래밍이란 결국 문제를 일반화하고 추상화하는 방법이고, 자바와 같은 정적인 객체 지향 언어에서는 이를 '유형(Type)'이라는 기초 단위를 통해 접근하는 패러다임을 택하고 있습니다.

    그렇다면 결국 자바 언어에서 모든 설계의 근본은 가장 추상적인 유형인 인터페이스를 중심으로 이루어질 수 밖에 없습니다. 단적으로 자바의 기본 API나 스프링 프레임워크등에 얼마나 많은 인터페이스가 포함되어 있는지 살펴보면 이 점은 명확하리라 생각합니다.

    만일 SI 프로젝트에서 '모듈 교체할 게 아니면 인터페이스는 쓰면 안된다'와 같은 불문율 같은 것이 있다면 그건 그런 프로젝트에선 애초에 추상화를 통한 모델링 자체를 하지 않는다는 이야기가 될 뿐입니다.

    현실적으로 그런 방식을 쓰는 것이 어쩔 수 없다고 이야기하는 건 몰라도, 최소한 그런 상황을 정상으로 생각하진 않았으면 좋겠습니다. 최소한 어떤 관행이 잘못됐고 어떤 모양이 맞는 것인지에 대해선 공감대가 있어야 시간이 지나면 나아지는 것을 기대할 수 있지 않을까요?

    2
  • 하마
    6k
    2016-03-04 20:31:57

    객체지향에서의 인터페이스, 서로 다른 시스템간의 인터페이스, DI(유연한 교체) 를 구분 못하시분이 계시네요.


    왜 쓰는지를 이해하기 위한 가장 쉬운방법은 GoF 패턴과 POSA 1을 보는겁니다.
    선현들이 고맙게 정리해둔 십여개의 인터페이스 활용예와 의도가 있답니다. :-)

    1
  • 욥욥욥
    909
    2016-03-04 21:56:39

    일단  일반적으로(?) 많이 사용하는 Service, Dao 의 Interface만 가지고 얘기하자면..

    이전 스프링의 AOP 가 Proxy 방식이 기본일 때, 어쩔 수 없이 Interface를 사용했어야하는 부분을 오해하고 쭉 사용해온 케이스가 대부분이라고 생각하는데요..

    Proxy 를 사용했을 때는 Interface 가 있어야 AOP 기능을 사용할 수 있었고, 지금은 cglib 가 기본으로  Interface 없이 Proxy 객체를 생성할 수 있습니다.

    Interface 없이 AOP 가 가능하다는 거죠.

    일반적으로들 많이 사용하시는 Service 나 Dao 구현체를 다른 구현체로 바꿀 상황이 얼마나 있으셨나요?

    저도, 주변에도 거의 없어 보이거든요.

    그리고 정말로 Interface 가 필요한 상황이면 그때가서 XXService, XXServiceImpl 로 리펙토링 하는게 그리 시간 걸릴 거 같지 않습니다.

    참조하는 다른 곳에도 지장은 없고요..

    이상 일반적으로(?) 많이 사용하는 Service, Dao 의 Interface 에 대한 얘기였구요 그 외 공통 모듈/설계 같은 부분에는 많이 사용되죠.


    그런데 글 쓴분은 주변에 뭔가 짜증이 나신거 같은데요

    공감가게 잘 만들어서 코드리뷰 한번 해주시면 끄덕끄덕하고 받아드릴 것 같은데

    뭔가 인정을 못 받으시는 건지.. ㅎㅎ




    0
  • 지붕뚫고높이차
    808
    2016-03-05 00:46:31

    fender 님


    문제를 해결하려면

    문제를 이해하려고 노력해야 합니다.

    그리고 두번째는 이해한 문제를 해결하기위해 제시한 내용을 이해하려고 노력해야 합니다.

    그 내용을 확대/극단적으로 해석하면 더 이상 의견 교환이 어려워집니다.


    그것도 상대방이 이해하기 어려운 용어와 문장을 써 가면서

    당신은 공부를 해야 하고

    당신의 생각은 틀렸다고 이야기 하니 아주아주X200 기분이 나쁘네요.


    객채지향 언어 특성인 추상화, 상속, 다형성, 캡슐화, 위임

    객체지향 5대 원칙인 SOILD 이해를 하시고

    인터페이스의 사용 이유에 대해 접근하시기 바랍니다.
    (객체 지향 언어를 공부할 때 배우는 가장 기본적 지식입니다.)

    라고 하면 잘 이해가 되시나요?


    인터페이스가 필요 없다고 이야기 한것도 아니고

    생명주기가 같은 2개 이상의 모듈을 교체하는 이슈가 아니면 인터페이스 사용은 교체비용보다

    수정비용이 크기 때문에 사용하면 안된다고 이야기 하였습니다.

    그 이야기가 무.조.건 인터페이스를 쓰면 안된다고 이해를 하신거라고 하면

    정말로 할 말이 없습니다.


    그리고 제 생각에 대해 반론하면서

    도.대.체 마커인터페이스를 언급한 이유는 뭔가요?

    마커 인터페이스가 응집도를 높히는데 유용해서 쓰신건가요?

    결합도도 높히고?

    설.마. 제가 인터페이스를 사용하지 않는 개발자라고 생각하신건가요?


    더 비아냥 거리고 싶지만 참겠습니다.

    뭐. 비아냥 거릴 내용도 없어요.

    0
  • fender
    17k
    2016-03-05 08:55:48

    지붕뚫고높이차 //

    뜬금없이 저에 대한 분노를 쏟아 내셔서 적잖게 당황스럽습니다만, 우선 본인이 쓴 내용부터 상기 시켜 드리겠습니다:

    "수정요구가 많고 모듈의 교체 이슈가 없는 업무에서는 절대로 사용하지 말아야 합니다... (중략)... 인터페이스의 필요성에 대해 다들 좋은 의견을 이야기 하셨는데 수정이 아닌 교체비용을 줄이기 위해 사용합니다. 그게 아니라면 사용하지 마세요."


    이 걸 '인터페이스는 구현체의 원활한 교체를 위해 사용하며 그렇지 않은 경우엔 사용하지 말아야 한다'라는 주장으로 이해했습니다만, 그 게 말씀하신 '극단적 확대, 과장'에 해당하는 건가요?

    어쨌건 중요한 건 저 주장은 틀.렸.다.는 겁니다. 그리고 전 님처럼 남의 아이디 직접 언급해가면서 "너 SOLID는 알어?" 따위로 비아냥 거린 것도 아니고 단지 반례를 들어 설명을 한 것 뿐입니다.

    (그런데 제 글의 '의사 코드', '마커 인터페이스' 같은 용어가 님이 사용한 'SOLID', '결합도', '응집도' 같은 개념 보다 뭐가 그렇게 대단해서 제가 '상대방이 이해하기 어려운 문장'을 쓰느니 마느니 비난하는 건가요?)

    마커 인터페이스의 반례를 이해 못하셨다면 다시 풀어서 설명을 드리겠습니다. 님의 주장대로라면 인터페이스는 구현체가 다수 존재하고 상황에 따라 교체해서 사용할 가능성이 있을 때 만 유효한 것인데, 그럼 `java.io.Serializable`의 '교체할 수 있는 구현체'는 뭐가 있는지 생각해보신 적 있나요?

    흔히 사용하는 'java.util.ArrayList'의 상위 인터페이스는 'Serializable', 'Cloneable', 'Iterable', 'Collection', 'List', 'RandomAccess' 입니다만, 'Cloneable'을 상속 받는 건 'Cloneable'을 쓰고 싶을 때 다른 구현체와 대체해서 결합도를 떨어뜨리기 위한 목적인가요? 'RandomAccess'는 또 어떨까요?

    자바에선 인터페이스에 실제 코드를 쓸 수 없습니다만, 예컨대 스칼라 같이 그런 제약이 없는 경우의 '믹스인(Mixin)'과 같은 용법을 생각해보면 그런 주장이 무엇을 놓치고 있는지 깨달을 수 있을 것이라 기대합니다. 그리고 그런 인터페이스의 본질적인 이해는 님이 언급한 'SOLID 원칙' 같은 것보단 훨씬 더 일반적이고 근본적인 이야기입니다.

    '인터페이스는 단지 모듈 교체를 위해 사용하는 것'이라고 주장하는 건 마치 '스프링은 단지 MVC 웹 어플을 만들 때 쓰는 것'이라는 말이나 비슷한 수준의 이야기입니다.

    저는 그게 스프링의 전부이거나 본질이 아니다라는 걸 지적한 것 뿐이고, 님은 그에 대해 '뭐라고? 그럼 스프링이 MVC가 아니란 거냐? 너 모델2라고 들어봤음?'하고 발끈하고 있는 것 같군요.

    전 님에게 개인적 감정 같은 것도 없고 주말에 인터넷에서 싸우고 싶은 생각도 없습니다. 제 글의 원래 목적이 님이나 다른 누구의 무지에 대해 비아냥 거리기 위한 것도 아니고, 인터페이스에 대한 본인의 주장의 잘못된 점을 깨달으셨으면 그냥 '오해가 있었다' 수준으로 마무리 하시면 저도 그 걸로 깔끔하게 잊어버리고 넘어가겠습니다.

    2
  • 난리닷
    750
    2016-03-08 18:36:48

    Interface를 왜 쓰냐고 하시는걸보니

    객체 지향의 진 면목을 아직 모르시는거 같아요..


    나중에 디자인패턴 보시면은 정말 설계에 아름다움에 감탄한답니다... 우와 하구

    0
  • apovr35
    278
    2016-03-10 20:17:30

    와드

    0
  • 2년마다매너리즘
    62
    2019-06-13 17:12:04

    인터페이스 왜 쓰는지 아세요? 라는 질문에


    지붕뚫고 높이차님의 이야기는  90프로 수긍할 수 있는 내용입니다. 

    물론 너무 과격하게 "수정이 아닌 교체비용을 줄이기 위해 사용합니다.

    그게 아니라면 사용하지 마세요." 라고 하셨지만 인터페이스를 남발하는 것보다야 안쓰는게 나은거 같아 저 표현이 과해 보이지는 않네요.


     

    "언어를 막론하고, 프로그래밍이란 결국 문제를 일반화하고 추상화하는 방법이고, 자바와 같은 정적인 객체 지향 언어에서는 이를 '유형(Type)'이라는 기초 단위를 통해 접근하는 패러다임을 택하고 있습니다."

    모호하고 이해하기도 힘들고.. 수긍하기도 힘든 본인 생각을 적으면서 왜 좋은글을 태클거세요 ㅋ  

    최소한 이런 상황을 정상으로 생각하진 않았으면 좋겠습니다. 



    0
  • fender
    17k
    2019-06-13 17:17:40
    0
  • 하긴 인용한 부분을 다시 곱씹으면서 읽으니 딱히 아니라고 할 수도 없겠네요 ㅎ

    " 수긍하기도 힘든 본인 생각을 적으면서" 는 취소하도록 하겠습니다 ~

    빠른 인정

    0
  • 로그인을 하시면 댓글을 등록할 수 있습니다.