인터페이스와 구현체를 활용하는 실사례를 알고 싶습니다.

[나형주]

스프링을 보면 항상 Service → ServiceImpl 형태로 개발하여 사용하게 됩니다.

물론 Service 자체를 빼버릴수도 있지만... 많은 프로젝트는 Service가 필요없음에도 불구하고 불필요한 이중관리, 개발, 수정을 하고 있습니다.

저는 항상 Service(인터페이스)를 빼버리는 데요. 인터페이스가 필요한 구체적인 실사례를 알고 싶습니다.

날씨가 많이 춥습니다. 건강에 유의하시길...

[Jisung Ahn]

1. Interface Segregation Principle

2. 교체 할 필요가 있을 때/메시징(다형성)이 필요할때 

3. Spring AOP를 적용하고 싶을때

4. Framework를 구성하고 싶을때 

모든 추가 설계는 "필요"할때 하는게 좋긴 합니다. 

2016년 1월 21일 오전 9:29, 나형주 <nhj1...@gmail.com>님이 작성:

--
이 메일은 Google 그룹스 'Korea Spring User Group Q&A' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 ksug+uns...@googlegroups.com에 이메일을 보내세요.
https://groups.google.com/group/ksug에서 이 그룹을 방문하세요.
웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/9cd2c1d6-fba2-4480-929b-edb174695ba6%40googlegroups.com을(를) 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

[나형주]

Spring AOP는 인터페이스가 아니어도 가능하지 않나요?

[나형주]

제 프로젝트는 인터페이스 없이 aop가 적용되어있습니당....

저는 스프링에서의 실 사용 사례가 궁금하네요 ^^;;

경험이 있으신분이 있는지...

[Jisung Ahn]

스프링에서 AOP는 인터페이스를 사용하는 Java Proxy 기반의 AOP, CGLib을 사용하는 AOP, AspectJ Weaving을 이용하는 3가지로 구성되고, 그중에서 복잡도나 성능이 제일 나은편인 인터페이스 기반의 AOP를 쓰는게 좋다고 하긴합니다. 

2016년 1월 21일 오후 1:53, 나형주 <nhj1...@gmail.com>님이 작성:

Spring AOP는 인터페이스가 아니어도 가능하지 않나요?

--

이 메일은 Google 그룹스 'Korea Spring User Group Q&A' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 ksug+uns...@googlegroups.com에 이메일을 보내세요.
https://groups.google.com/group/ksug에서 이 그룹을 방문하세요.

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/326bebf1-baa7-46d3-ace6-4ae25006950a%40googlegroups.com을(를) 방문하세요.

[Jisung Ahn]

기술적 요구사항 말고, 비지니스 요구에 의해 인터페이스를 사용한다면 저의 경우  대부분 기능 치환성때문입니다.

기능 치환의 예를 들어 보자면..

1. 일반 로그인 vs 성능테스트를 위해 로그인절차를 일부 생략한 로그인 

2. 일반 메일 발송 vs 스테이징 서버등에서 테스트과정에 실제 고객에게 메일 발송하기 않게 한 메일 발송 

3. NAS로 파일 업로드 vs NAS가 없는 스테이징 서버등에서 BO에서 업로드한 파일을 동시에 Front 에서도 보기 위해 Front 서버로 FTP로 업로드 하기 

4. A/B 테스트 하기

이런것 들이 있겠네요 

2016년 1월 21일 오후 1:58, Jisung Ahn <nar...@gmail.com>님이 작성:

[Sanghyuk Jung]

'스프링을 보면 항상 Service → ServiceImpl 형태로 개발하여 사용하게 됩니다.'이라고 하셨는데, 항상까지는 아니고,  제 주변에는 반반쯤 되지 않나 싶군요.

저도 실용적으로, Interface가 필수적이라고는 생각하지는 않는습니다.  테스트 코드를 짜는데 큰 어려움이 없다면 바로 concrete class에 의존해도 괜찮다는 사상을 가지고는 있습니다. 요즘은 AOP나 mock라이브러리의 제약이 적어져서  interface없이 만드는 경향이 더 늘어나고 있는것도 같습니다.

다만 담당자가 다르거나 별도의 jar로 배포하는 등 layer간의 강한 경계를 유지할 필요가 있을 경우, One interface- one implmentation이라도 interface를 만드는게 좋다고 봅니다.  인터페이스 파일의 변경 이력만 보고 신경쓰면 되므로 버전관리나 변경추적에 유리한 면이 있습니다.

그래서 라이브러리를 만들때는 implentation클래스가 하나밖에 없을  때라도 가급적 interface를 추출하는 것이 좋다고 생각합니다.

다른 이유들은 다른 분들이 추가로 설명해주실거 같네요.

2016년 1월 21일 오후 2:11, Jisung Ahn <nar...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/CA%2BOh4E63uVZYbHCNwyTnH229EHGT9KpEZusEz9hkCoiWLik%2Bbw%40mail.gmail.com을(를) 방문하세요.

[SangYong Lee]

실사례라면... 게시판이 있죠...

공지사항 : 관리자만 쓰기 / 덧글기능없음 / 첨부파일있음

일반 게시판 : 회원만 쓰기 / 덧글목록추가 / 첨부파일없음

문의 게시판 : 누구나 쓰기 / 덧글기능없음 / 첨부파일있음

하나의 interface 로 implements 해서 각 권한별 게시판별로 구현했습니다.

모듈화되어있어서 같이 개발하는 개발자들은 하나의 인터페이스만 호출하면 나머지는 자동으로.. 

저는 interface는 되도록이면 사용해야된다고 생각하는 1인이라서^^;; 굳이 필요가 없더라도.. 왠만하면 만들어서 사용하는 편입니다.

기능을 확장하거나, version을 구분할때도 유용하게 사용할 수 있습니다.

2016년 1월 21일 오후 2:47, Sanghyuk Jung <ben...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/CAP8AxAtee_uMcZmyw2_EHvjka_TyTvBHQo%3DJL_0vopCAq4QWnQ%40mail.gmail.com을(를) 방문하세요.

[YongHyeok Lee]

개발하는 순서 때문이라도 인터페이스를 사용합니다.

인터페이스로 우선 업무설계를 하고..

구현체로 로직을 구현하는 방법인데요..

다들 이렇게 하는거 아니었나요? ㅎㅎ

일부 유틸성으로 직관적인 클래스들은 인터페이스 없이 사용하는 경우도 있습니다.

나의 iPhone에서 보냄

2016. 1. 21. 18:39 SangYong Lee <dd.st...@gmail.com> 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/CAJdskF8RvbqjLoLFww4XZXrMr7dD_1KimRLCP9t_nDpCW1SKHA%40mail.gmail.com을(를) 방문하세요.

[나형주]

// narusas

치환성이라는 말씀은 두가지를 경우에 따라 선택적으로 사용할 수 있다는 이야기 맞나요? 선택적으로 구현체를 고를수 있는건가요?

// UnLogical

인터페이스와 클래스를 두가지 관리하면서 얻을 수 있는 강점이 무엇인가요?

// 정상혁

 layer간의 강한 경계를 유지할 필요가 있을 경우 라는 말씀은 어떤 말씀이신지요?? 제가 이해를 잘 못했습니다. ㅠㅠ

인터페이스는 구현체의 함수내부를 변경하는 경우 변경이력이 없을텐데 변경 및 추적의 용이성을 말씀하시는 이유는 어떤것인지요?

2016년 1월 21일 목요일 오전 9시 29분 55초 UTC+9, 나형주 님의 말:

[나형주]

UnLogical 님 질문을 수정해야 될것 같아서...

  -> 단일 인터페이스와 단일 클래스를 두가지 이중 관리하면서 얻을 수 있는 강점이 무엇인가요?

2016년 1월 21일 목요일 오전 9시 29분 55초 UTC+9, 나형주 님의 말:

스프링을 보면 항상 Service → ServiceImpl 형태로 개발하여 사용하게 됩니다.

[Jisung Ahn]

기능 치환성 -> 

예. 동적이든 정적이든 가능해집니다. 

정적(부트스트랩 단계에서)으로 선택한다면 스프링 프로필을 참고하시고, 동적(실행중에 조건에 따라)으로 선택한다면 Feature Toggle을 참고하시면 됩니다. ( http://martinfowler.com/bliki/FeatureToggle.html  또는 http://www.togglz.org/ )

layer간 강한 경계 -> 

그냥 사용하는 클래스, 함수가 아니고 API형태로 제공하여 개인/팀 간의  Provider-Consumer 경계를 명확히 하는 경우라면, 라이브러리의 사용자 입장에서는 "사용 계약(Contract)"이 인터페이스이며, 인터페이스가 변경되지 않으면 계약이 유지된다고 볼수도 있지요. 

심지어 공개된 API를 갱신해야 할때  기존 인터페이스를  고치는 것보다 Version Interface를 이용해 추가 API형태로 제공하는 경우도 있으니까요 

2016년 1월 22일 오전 10:05, 나형주 <nhj1...@gmail.com>님이 작성:

--

이 메일은 Google 그룹스 'Korea Spring User Group Q&A' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 ksug+uns...@googlegroups.com에 이메일을 보내세요.
https://groups.google.com/group/ksug에서 이 그룹을 방문하세요.

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/f820ec1c-7a5d-46ef-8215-2724374278ab%40googlegroups.com을(를) 방문하세요.

[Jisung Ahn]

사실 인터페이스와 구현을 분리하는 가장 큰 이유는,  인간의 인지능력 제약 때문입니다. 

사람은 한번에 7개 이상의 사실을 동시에 고려하면서 정신적인 일을 할수 없으며, 7개라는 숫자는 인지능력이 매우 좋은 사람의 경우이고 보통의 사람은 3~4개정도만을 고려 할수 있습니다. 

그러므로 한번에 신경쓸게 적게 하는 방법을 찾다보면, 결국 한번에 신경쓸것을 줄이자라는 방법을 추구하게 됩니다. (모듈/캡슐화/...)

인터페이스/메소드명만 보고 그게 무슨일을 할지 알 수 있다면, 복잡한 구현을 볼 필요가 없겠지요. (심지어는 구현도차도 동적으로 만들어 낼수도 있으니까요. 대표적인 예라면 Spring Data JPA의  Repository를 한번 찾아보세요)

그럼 메소드명만 좋아도 되지 않느냐라고 생각할수 있지만, 인터페이스는 여기에 관련된 메소드들을 모아두었다라는 문맥을 제공하여 GoodsRepository라는 인터페이스만 봐도  상품과 관련된 조회는 여기서 하면 되겠구나라는, 메소드명을 보지 않아도 되게하여 인지 부하를 낮춰줍니다. 

그런데 문제는....

OOP에 익숙하지 않은 개발자가 보기에 이것이 불필요한 작업으로 보이며, 클래스의 숫자가 많아 지기 때문에 더 "복잡"하다고 느낍니다. 

 

이런 편견을 악화 시키는 것이 프로젝트에서 기술적/관례적으로 기계적으로 찍어내는 인터페이스/구현 입니다. 메소드 한두개 만들고 싶은건데 클래스가 두개나 되는건 매우 복잡한 거라고 생각하죠. 

모듈화나 OOP를 잘 하다 보면 작은 모듈/클래스가 많아 지는 경향이 있는데,  OOP를 잘하는 사람은 "단일 책임"을 가지게 되어서 "쉬워졌다"고 보지만, 아닌 사람은 클래스가 "많아져서" 오히려 "복잡해졌다"라고 보더라고요. 

저는 이런 것때문에 디자인 추가는 "필요"할때 하는게 좋다고 적었던 건데요.  생각보다 어려운 주제입니다.  개인적 욕심과 프로젝트 팀원 수준 고려등등...

2016년 1월 22일 오전 10:24, Jisung Ahn <nar...@gmail.com>님이 작성:

[YongHyeok Lee]

두개를 왜 다 관리하세요..

두개가 원래 하나이면서..

두개의 용도가 서로 서로 다른겁니다.

인터페이스는 설계에 관련된 클래스이고..

구현체는 말 그대로 구현체인거지요..

인터페이스로 업무를 파악할 수 있고..

구련체로는 개별 단위업무의 실제 로직을 확인하는거지요.

인터페이스 자체에 구현에 대한 주석이 포함되어 있어야 하는거고요..

구현은 누군가 알아서 잘 하겠죠.

그게 본인일수도 있고요..

구현체 자체에 근본적인 구현 방식의 차이가 생긴다면, 별도의 구현체를 만들어도 되는거고요.

나의 iPhone에서 보냄

2016. 1. 22. 10:05 나형주 <nhj1...@gmail.com> 작성:

--

[허준형(許準亨)_HurJoonHyung]

님 의견이 가장 명쾌한 답이네요.

현업 개발자로서 가장 공감이 됩니다.

2016년 1월 22일 오전 11:07, YongHyeok Lee <unlogi...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/6B292850-17D7-4E01-817B-5B4A51210506%40gmail.com을(를) 방문하세요.

[Sanghyuk Jung]

네,  레이어간 경계에 대해서 제가 답변드릴 사안은 Jisung Ahn님께서 대신 잘 설명해주셨네요.

Consumer는 interface의 변화만 신경쓰면 된다는 것을 명확히 할수 있다는 것이죠.  큰 변경에 대한 히스토리를 추적할때 구현체의 변경 commit까지 볼 필요 없어져서 봐야할 diff가 줄어듭니다.  인터페이스 파일의 commit만 골라 보거나 blame 명령으로 파악할수 있으니까요.

오래된 코드의 commit을 볼일이 많은 업무를 했을때  그런 점을 느꼈습니다.

2016년 1월 22일 오전 11:15, 허준형(許準亨)_HurJoonHyung <june7...@gmail.com>님이 작성:

웹에서 이 토론을 보려면 https://groups.google.com/d/msgid/ksug/CALAG_aPOtDYPG%3Dp4-7J3dtiTGvtdjmr1BiV_N0k6XJC9QR8PWQ%40mail.gmail.com을(를) 방문하세요.

[나형주]

답변 주신 분들의 지식 나눔에 감사드립니다.

 "필요"할때 하는게 좋다 많은걸 생각하게 해주는 말씀입니다.

2016년 1월 21일 목요일 오전 9시 29분 55초 UTC+9, 나형주 님의 말:

스프링을 보면 항상 Service → ServiceImpl 형태로 개발하여 사용하게 됩니다.