티스토리 뷰
왜 service 개발시 항상 impl 인터페이스를 만드나요?
MVC 패턴에서 Service를 개발할 때 항상 Interface를 생성하고 implements 해서 사용을 하는데 그래야 하는 이유가 있나요?
왜 그렇게 써야만 하는지, 그렇게 안쓰면 생기게 되는 문제는 무엇인지 지식인분들의 답변 부탁드립니다.
MVC 패턴과는 상관이 없습니다. MVC에서는 Controller에서 Service를 호출하는 방법에 대해서는 상관하지 않는 것이라..
첫번째, OOP에서 interface를 사용하는 이유와 같은 이유로 서비스 부분에 interface를 지정하는 것입니다.
일반적으로 웹 프로그램에서는 서비스 + DAO까지 하나의 컴포넌트로 외부(Controller)에 제공되기 때문에
인터페이스를 사용하여 대체 가능성 등을 고려하는 것이지요..
구체적인 인터페이스의 장점: ____에 대해서는 차후 서술
두번째, 일반적으로 transaction이나 Exception 처리 등의 AOP 설정이 서비스 경계 부분에 지정되기 때문입니다.
Spring의 경우도 이 부분의 인터페이스화 되어 있지 않으면 CGLIB같은 class를 변경하는 추가적인 설정과 library가 필요합니다.
이는 추가 설정이 필요한 측면도 있고, 내부적으로 복잡하게 동작하기 때문인 것 같습니다.
(물론 CGLIB과 같은 경우는 처리 속도가 더 좋다는 결과도 있습니다.)
CGLIB: ___________
CGLIB는 코드 생성 라이브러리로서(Code Generator Library) 런타임에 동적으로 자바 클래스의 프록시를 생성해주는 기능을 제공한다.
CGLIB를 사용하면 매우 쉽게 프록시 객체를 생성할 수 있으며, 성능 또한 우수하다. 더불어, 인터페이스가 아닌 클래스에 대해서
동적 프록시를 생성할 수 있기 때문에 다양한 프로젝트에서 널리 사용되고 있다. 예를 들어, Hibernate는 자바빈 객체에 대한 프록시를 생성할 때 CGLIB를 사용하며, Spring은 프록시 기반의 AOP를 구현할 때 CGLIB를 사용하고 있다
단답형으로 말하면 loose coupling을 하려는 것이죠.
커플링 :
커플링 (Coupling) 은 응집도(Cohesion)과 함께 소프트웨어 설계의 품질을 판단하는 척도 입니다. 매우 중요한 개념이지만 정확하게 설명하는 글을 찾기가 쉽지 않습니다.
모든 설계에 관한 글에서 커플링을 느슨하게 하라고 말합니다. 느슨한 커플링 이더라도 너무 많은 커플링은 전체를 타이트 하게 만듭니다.
커플링이란 완벽하게 제거되야할 악의 축인 것일 까요?
아래의 포스트는 IEEE SOFTWARE 에 2001년 파울러가 기고한 Reducing Coupling 글의 번역한 것 입니다.
커플링이란 무엇이며, 커플링을 줄이는 방법은 무엇인지 마틴 파울러 로 부터 배우 봅니다.
번역 :
Reducing Coupling
by 마틴 파울러.
IEEE SOFTWARE J u l y / A u g u s t 2 0 0 1 , Reducing Coupling , by Martin Fowler
커플링(Coupling)은 응집력(Cohesion)과 함께 설계의 품질을 결정하는 가장 오래된 지표 중 하나 입니다. 구조적 설계 때 부터 그 유산은 사라지지 않았습니다. 저는 소프트웨어를 설계 할때 항상 염두에 둡니다. 커플링을 설명하는 방법이 여러개가 있으나 다음으로 요약됩니다: 어떤 모듈을 변경할때 다른 모듈의 변경이 요구된다면 커플링이 존재합니다. 한 측면에서 두개의 모듈이 비슷한 일을 한다면 다른 코드에 중복되기 쉽습니다. 이는 명확하게 중복의 예 입니다. 중복은 언제나 커플링을 수반합니다. 두개의 코드 조각이 명확한 관계를 맺고 있지 않기 때문에 중복 지점을 집어내기란 쉽지 않습니다.
커플링은 또 어떤 모듈이 다른 모듈의 코드를 사용할 때 발생합니다. 아마도 데이터를 접근하거나 함수를 호출할 때 말이죠. 이런 경우에는 코드 중복과는 다르게 명확하게 집어 낼 수 있습니다. 커플링이란 완전히 제거 해야 하는 요소로 대할 수 없습니다. 여러분은 하나의 프로그램을 여러개의 모듈로 나눌 수 있지만 모듈들은 어떠한 방법으로든 커뮤니케이트가 필요합니다. - 다른 측면으로, 다수의 프로그램을 가지고 있을 때, 커플링은 바람직 합니다. 커플링을 완전히 제거하려 한다면 모든 것을 하나에 집어 넣은 거대한 모듈만이 남게 될 것입니다. 그리고 거기에는 매우 많은 커플링이 존재하게 됩니다. - 단지 러그(rug)로 덮어서 감추어 둔 것일 뿐이죠.
커플링은 우리가 통제해야 할 대상인 것입니다. 그러면 어떻게 통제 할 까요? 모든 곳에서 걱정해야 할 대상일까요? 아니면 더 중요한 특정 위치가 있는 걸 까요? 어떤 요소가 나쁜 커플링이라고 생각되며, 용인되는 커플링이란 어떤 것일 까요?
의존에서 살펴보기
높은 레벨의 모듈에서의 커플링에 대해 생각해 보았습니다. 우리가 시스템을 12개 정도의 큰 모듈 조각으로 나누었을때 이것들을 어떻게 묶을 까요? 저는 coarser-gained 모듈에 집중하였습니다. 모든 커플링을 고려하는 것은 불가항력이기 때문이죠. 가장 큰 문제는 상위(upper level)에서의 커플링을 통제할 수 없을 때 라는 것입니다. 저는 여러개의 모듈이 서로 묶여 있다 하더라도 걱정하지 않습니다, 하지만 모듈간의 의존(dependency) 관계의 패턴을 찾습니다. 이때 다이어그램을 이용하는 것이 매우 유용합니다.
제가 의존(dependency) 이라는 용어를 사용할 때는 UML에서 정의 된 것을 의미합니다. 고로 UI 모듈이 도메인 모듈의 어떤 코드를 참조 한다면, UI 모듈이 도메인 모듈에 의존한다고 말 할 수 있습니다.- 함수 호출, 데이터 이용, 도메인 모듈에 정의된 타입을 이용하는 것 말이죠.
어떤 사람이 도메인 모듈을 변경한다면 UI 모델의 변경이 요구됩니다. 의존(dependency)은 단방향성 입니다. : UI 모듈은 항상 도메인 모듈을 의존합니다. 다른 방법은 존재하지 않습니다. 도메인 모듈 또한 UI 모듈을 의존 한다면 우리는 두번째 의존을 가지는 것입니다.
UML 의존은 전이 불가(non transitive)를 의미합니다. UI 모듈이 도메인 모듈을 의존하고, 도메인모듈이 데이터베이스 모듈을 의존 한다면, 우리는 UI 모듈이 데이터베이스 모듈을 의존한 다고 가정할 수 없습니다. 그렇게 가정한다면 우리는 UI 모듈과 데이터베이스 모델을 직접적인 부가 의존을 기술해야 합니다. 이 비전이성(nontransivity)은 도메인모델이 데이터베이스의 변경으로 부터 UI를 격리시킨다는 것을 보여주기 때문에 매우 중요합니다. UI 는 오로지 도메인 모델의 인터페이스가 변경될 만큼 매우 많은 데이터베이스의 변경이 발생 했을 때에만 변경됩니다. 그림 1a 는 UML 표기를 이용한 다이어그램을 보여 줍니다. UML은 객체지향 시스템을 위해 설계 되었지만, 모듈의 기본 개념과 의존은 대부분의 소프트웨어에 적용됩니다.
이런 종류의 고-레벨(high-level) 모듈의 UML 이름은 패키지(Pakage) 입니다. 그래서 이후 부터는 이 용어를 사용하겠습니다. 패키지들 이기 때문에 저는 이런 종류의 다이어그램을 패키지 다이어그램(pakage diagram) 이라고 부르겠습니다. (UML 로 엄격하게 말해서는 클래스 다이어그램 입니다.)
여기에서 기술하려 하는 것은 레이어드 아키텍처(layered architecture) 입니다. 정보 시스템(information system)에서 종사하는 사람은 누구나 익숙 할 겁니다. 정보시스템에서 레이어는 우리가 의존을 생각할 때 반드시 고려해야 하는 어떤 것을 기술하는 좋은 재료입니다.
의존구조를 심사숙고하는 충고의 가장 공통적인 것은 순환을 회피 하라는 것 입니다. 순환은 여러분의 모든 변경이 다시 최초 패키지의 변경을 요구하기 때문에 매우 큰 문제입니다. 그런 시스템은 수차례에 걸쳐 순환하며 살펴 봐야 하기 때문에 이해하기가 매우 어렵습니다. 저는 엄격한 규칙으로서 패키지들 사이의 순환 회피를 보여주여줄 필요를 느끼지 않습니다.-그것들이 지역화 되어 있다면 저는 관대할 겁니다.
Interface의 정의 중에 여러 곳에서 implements 함으로써 얻는 장점들이 많다는걸 알 수 있는데
프로젝트를 진행하다 보면 서비스 하나당 인터페이스를 하나씩 만들어서 쓰고 있습니다.
즉 재사용성은 없는데
OOP와 AOP를 제대로 갖추기 위해 쓰는건 맞는데 우리나라 IT 현실에서 이걸 쓰는건 사실 회의적일때가 많네요;;
어차피 스파게티 소스도 넘쳐나게 섞어 쓰고, 정작 저렇게 구현해놓고선 제대로 쓰질 않으니 유명무실한 경우가 참 많죠
이걸 이따위로 쓰려면 왜 이걸 가져왔나...참 한탄스럴때가 있는데 어쩔수 없네요;;
service에서 쓰는건 스프링에서 AOP구현시 사용하는게 JDK의 기본 프록시인데
프록시는 Inteface기반으로 동작해서 그냥 저게 싫음 CGLib로 쓰면됨
어짜피 스프링도 CGLib는 3버전이후로는 포함되어 있음
인터페이스 자체의 사용 이유는 그냥 규약이 필요할때 쓰면됨