서비스단 클래스 구조에 관련하여 질문드립니다.
- 작성자 :
- 김*성
- 작성일 :
- 2016-03-29 22:10:56
- 조회수 :
- 794
- 구분 :
- 공통컴포넌트
- 진행상태 :
- 완료
Q
안녕하세요...서비스단 클래스 구조에 관련하여 질문드립니다.
다름아니오라 공통컴포넌트에서 제공하는 기능을 구현하는 클래스 구조를 보면 각 모듈별로 service interface 가 있고 이를 구현하는 serviceImpl 클래스가 각각 존재 합니다. 여기서 질문입니다. 만약 프로젝에서 개발해야 하는 기능들이 1000개 라고 하면 생성해야하는
service interface 도 1000개를 만들어야 하는데 제생각에는 너무 비효율적이라고 생각합니다. interface class를 쓰는 많은 이유중 확장성과 기능재구현? 인데 제가 많은 프로젝트를 참여하면서 service interface를 확장하거나 재구현한 기억이 한번도 없습니다. 이런 유로 프로젝트에 참여를 할때마다 스트레스입니다. 왜 불필요한 interface 클래스를 만들어야하는지 이해를 못하겠습니다.
주관적인 생각으로 interface 오남용이라고 생각합니다.
물론 불필요한 interface 를 안쓰는대신 이를 대체할 다른 클래스 구조를 강구해야겠지만 이문제는 논외로 하고,
진짜 질문... 위에서 언급한 클래스 구조를 유지해야 하는 이유 와 장점등을 알고싶습니다.
물론 개발하는 본인이 원하는 스타일로 클래스 구조를 만들면 되는 문제이긴 하지만
많은 프로젝트가 eGov의 클래스 구조를 그대로 따라 하다시피 개발표준으로 정하기때문에
어쩔수 eGov의 클래스 구조 기반으로 개발을 해야하는 경우가 많습니다.
대국민을 상대로 공개해야하는 입장에서 제가 너무 쉽게 질문을 한것같아 송구스럽지만...넓은 아량으로 답변 부탁드립니다.
클래스 구조를 좀더 효율적으로(기계적으로 만드는 service interface를 만들지않고) 바꾼다면 eGov의 클래스 구조를
그대로 따라하는 현 상황에서 좀더 개발 생산이 높아지지 않을까 하는 짧은 생각 에 질문을 남깁니다.
감사합니다.
마지막으로 질문 작성 할 수 있는 시간이 넉넉치 않아 두번이나 날려먹었습니다...로그인 세션시간좀 늘려주세요...
다름아니오라 공통컴포넌트에서 제공하는 기능을 구현하는 클래스 구조를 보면 각 모듈별로 service interface 가 있고 이를 구현하는 serviceImpl 클래스가 각각 존재 합니다. 여기서 질문입니다. 만약 프로젝에서 개발해야 하는 기능들이 1000개 라고 하면 생성해야하는
service interface 도 1000개를 만들어야 하는데 제생각에는 너무 비효율적이라고 생각합니다. interface class를 쓰는 많은 이유중 확장성과 기능재구현? 인데 제가 많은 프로젝트를 참여하면서 service interface를 확장하거나 재구현한 기억이 한번도 없습니다. 이런 유로 프로젝트에 참여를 할때마다 스트레스입니다. 왜 불필요한 interface 클래스를 만들어야하는지 이해를 못하겠습니다.
주관적인 생각으로 interface 오남용이라고 생각합니다.
물론 불필요한 interface 를 안쓰는대신 이를 대체할 다른 클래스 구조를 강구해야겠지만 이문제는 논외로 하고,
진짜 질문... 위에서 언급한 클래스 구조를 유지해야 하는 이유 와 장점등을 알고싶습니다.
물론 개발하는 본인이 원하는 스타일로 클래스 구조를 만들면 되는 문제이긴 하지만
많은 프로젝트가 eGov의 클래스 구조를 그대로 따라 하다시피 개발표준으로 정하기때문에
어쩔수 eGov의 클래스 구조 기반으로 개발을 해야하는 경우가 많습니다.
대국민을 상대로 공개해야하는 입장에서 제가 너무 쉽게 질문을 한것같아 송구스럽지만...넓은 아량으로 답변 부탁드립니다.
클래스 구조를 좀더 효율적으로(기계적으로 만드는 service interface를 만들지않고) 바꾼다면 eGov의 클래스 구조를
그대로 따라하는 현 상황에서 좀더 개발 생산이 높아지지 않을까 하는 짧은 생각 에 질문을 남깁니다.
감사합니다.
마지막으로 질문 작성 할 수 있는 시간이 넉넉치 않아 두번이나 날려먹었습니다...로그인 세션시간좀 늘려주세요...
A
김용성님 안녕하세요.
표준프레임워크센터입니다.
표준프레임워크에서는 말씀하신대로 서비스 레이어의 구성을 인터페이스와 구현클래스로 구성을 하고 있습니다.
경우에 따라서 요구하신 것 처럼 인터페이스의 영역이 불필요하게 느껴지실 수 있으나 이는 재사용기능을 위한
아키텍처 설계에 따른 구성이라 보시면 될 것입니다.
불필요하게 다수의 interface를 생성하는 이슈는 설계상의 이슈로 보입니다.
서비스에 따라 각각의 인터페이스가 구성될 필요는 없습니다. 업무특성을 고려하여 공통적인 기능은 하나의 서비스로 구성하여
인터페이스를 만들고 구현체는 각각의서비스에 필요한 기능들로 구성되어있는지 검토해보시기 바랍니다.
예를들어 알림 기능을 처리하는 서비스를 구성할 경우 서비스 레이어에서 인터페이스로 알림 서비스를 구성한 다음
이메일로 알림을 처리할 지, 문자메시지로 알림을 처리할 지 기능을 구성하게 되는데
이러한 기능적인 부분을 비지니스 로직과 분리하여 재사용 및 상황에 대한 서비스대응이 유연하도록
설계 당시 고려한다고 보면 되겠습니다.
감사합니다.
p.s
* 인터페이스와 구현체 구성의 경우 표준프레임워크 필수가 아닌 권장사항입니다.
* 세션시간은 보안이슈에 영향이 있는 부분이라 내부적으로 개선여부를 검토하여 반영하도록 하겠습니다.
표준프레임워크센터입니다.
표준프레임워크에서는 말씀하신대로 서비스 레이어의 구성을 인터페이스와 구현클래스로 구성을 하고 있습니다.
경우에 따라서 요구하신 것 처럼 인터페이스의 영역이 불필요하게 느껴지실 수 있으나 이는 재사용기능을 위한
아키텍처 설계에 따른 구성이라 보시면 될 것입니다.
불필요하게 다수의 interface를 생성하는 이슈는 설계상의 이슈로 보입니다.
서비스에 따라 각각의 인터페이스가 구성될 필요는 없습니다. 업무특성을 고려하여 공통적인 기능은 하나의 서비스로 구성하여
인터페이스를 만들고 구현체는 각각의서비스에 필요한 기능들로 구성되어있는지 검토해보시기 바랍니다.
예를들어 알림 기능을 처리하는 서비스를 구성할 경우 서비스 레이어에서 인터페이스로 알림 서비스를 구성한 다음
이메일로 알림을 처리할 지, 문자메시지로 알림을 처리할 지 기능을 구성하게 되는데
이러한 기능적인 부분을 비지니스 로직과 분리하여 재사용 및 상황에 대한 서비스대응이 유연하도록
설계 당시 고려한다고 보면 되겠습니다.
감사합니다.
p.s
* 인터페이스와 구현체 구성의 경우 표준프레임워크 필수가 아닌 권장사항입니다.
* 세션시간은 보안이슈에 영향이 있는 부분이라 내부적으로 개선여부를 검토하여 반영하도록 하겠습니다.