기능별 패키지 접근 방식이 좋습니까?
최근 자바 코드를 기능별로 포장한 http://java.dzone.com/articles/how-changing-java-package 라는 게시물을 우연히 발견했습니다.
저는 그 생각이 마음에 들지만, 이 접근법에 대해 몇 가지 질문이 있습니다.저는 제 질문을 했지만 만족스러운 답변을 받지 못했습니다.StackOverflow에 있는 누군가가 제 질문을 명확히 해주길 바랍니다.
저는 코딩을 하는 동안 패키지를 가로질러 이동하는 시간을 크게 줄이고 모든 관련된 것들이 한 곳(패키지)에 있을 것이라는 기능별 패키지 아이디어가 좋습니다.하지만 서로 다른 패키지에 있는 서비스 간의 상호 작용은 어떻습니까?
블로그 앱을 구축하고 모든 사용자 관련 작업(컨트롤러/서비스/저장소)을 수행하고 있다고 가정합니다.com.mycompany.myblog.users꾸미러컨게관모(컨트롤러//리포지토리에 있는 모든 게시 /서비스/)com.mycompany.myblog.postspackage
이제 그가 올린 모든 게시물과 함께 사용자 프로필을 보여주고 싶습니다.에 전화해야 ?myblog.posts.PostsService.getPostsByUser(userId)myblog.users.UserController.showUserProfile()?
패키지 간 커플링은 어떻습니까?
또한 제가 패키지에 대해 기능별로 읽는 곳마다 모두가 그것이 좋은 관행이라고 말합니다.그렇다면 왜 많은 책 작가들과 심지어 프레임워크들이 층별로 그룹화하도록 장려합니까?그냥 궁금해서요 :-)
밥 아저씨의 패키지 디자인 원칙을 보세요.그는 제가 아래에서 자세히 설명한 원칙 뒤에 숨겨진 이유와 동기를 설명합니다.
함께 재사용되는 클래스는 패키지가 사용 가능한 일종의 완전한 제품으로 취급될 수 있도록 함께 패키지되어야 합니다.그리고 함께 재사용되는 것들은 재사용되지 않는 것들과 분리되어야 합니다.예를 들어 로깅 유틸리티 클래스는 fileio 클래스와 함께 사용할 필요가 없습니다.따라서 모든 로깅을 개별적으로 패키징합니다.하지만 로깅 클래스는 서로 관련이 있을 수 있습니다.따라서 더 나은 이름의 커먼즈 로깅 패키지가 필요한 경우, 더 나은 이름의 commons-io.jar와 같은 io 유틸리티를 위한 또 다른 별도의 완전한 제품을 로깅용으로 만듭니다.say commons-io 라이브러리를 support javannio라고 업데이트하면 로깅 라이브러리를 변경할 필요가 없습니다.그래서 그것들을 분리하는 것이 더 낫습니다.
이제, Splunk와 같은 도구에 의한 로그 분석을 위해 로깅 유틸리티 클래스가 구조화된 로깅을 지원하도록 했다고 가정해 보겠습니다.로깅 유틸리티의 일부 클라이언트는 최신 버전으로 업데이트하기를 원할 수 있지만 다른 클라이언트는 그렇지 않을 수 있습니다.따라서 새 버전을 릴리스할 때 마이그레이션에 필요하고 재사용되는 모든 클래스를 함께 패키지화합니다.따라서 유틸리티 클래스의 일부 클라이언트는 오래된 커먼 로그 병을 안전하게 삭제하고 커먼 로그 새 병으로 이동할 수 있습니다.몇몇 다른 고객들은 오래된 병에도 여전히 괜찮습니다.그러나 오래된 패키지 병에 대해 일부 클래스를 사용하도록 강제했다는 이유만으로 이러한 병(신규 및 구형)을 모두 가질 필요는 없습니다.
순환 종속성을 피합니다. a는 b; b는 c; c; c; d는 a에 의존합니다.계층이나 모듈 등을 정의하는 것이 매우 어렵고 서로 독립적으로 변경할 수 없기 때문에 시나리오는 분명 망설여집니다.
또한 계층 또는 모듈이 변경되더라도 다른 모듈 또는 계층이 반드시 변경될 필요가 없도록 클래스를 패키지화할 수 있습니다.예를 들어 기존 MVC 프레임워크에서 Rest API로 업그레이드하기로 결정한 경우 뷰와 컨트롤러만 변경해야 할 수 있습니다. 모델은 변경할 수 없습니다.
저는 개인적으로 "기능별 패키지" 접근 방식을 좋아하지만, 패키지 경계를 어디에 그릴지에 대해 상당히 많은 판단이 필요합니다.이것은 많은 상황에서 실현 가능하고 합리적인 접근법입니다.
공용 인터페이스를 사용하여 패키지와 모듈 간의 결합을 달성해야 합니다. 이렇게 하면 결합을 깨끗하고 관리할 수 있습니다.
"블로그 포스트" 패키지가 잘 설계된 공개 인터페이스를 사용하는 한 "사용자" 패키지로 호출하는 것은 완벽하게 좋습니다.
그러나 이러한 접근 방식을 사용한다면 한 가지 큰 조언이 있습니다. 종속성에 대해 매우 신중하고 특히 패키지 간의 순환 종속성을 피하십시오.좋은 디자인은 의존성 트리처럼 보여야 합니다. 유틸리티 기능의 라이브러리 등에 의존하는 공통 서비스 집합에 따라 더 높은 수준의 기능 영역이 있습니다.어느 정도는 프런트 엔드 패키지가 백엔드 서비스를 호출하는 아키텍처 "레이어"처럼 보이기 시작합니다.
패키지 디자인을 위한 커플링 외에도 많은 측면이 있습니다. 저는 OOOAD 원칙, 특히 패키지 디자인 원칙을 살펴보라고 제안합니다.
REP 방출 재사용 동등성 원칙 재사용의 과립은 방출의 과립입니다.
CCP 함께 변경되는 공통 폐쇄 원칙 클래스는 함께 패키지화됩니다.
CRP 함께 사용되는 공통 재사용 원칙 클래스는 함께 패키지화되어 있습니다.
ADP 비순환 종속성 원칙 패키지의 종속성 그래프에는 주기가 없어야 합니다.
SDP 안정적 의존성 원칙은 안정성의 방향에 따라 달라집니다.
SAP 안정적 추상화 원칙 추상성은 안정성과 함께 증가합니다.
자세한 내용은 "신속한 소프트웨어 개발, 원칙, 패턴 및 관행"을 참조하십시오.
언급URL : https://stackoverflow.com/questions/11733267/is-package-by-feature-approach-good
'programing' 카테고리의 다른 글
| jQuery: Backspace 키를 누르면 실행되지 않습니까? (0) | 2023.07.28 |
|---|---|
| 인스턴스 변수를 자동으로 초기화하시겠습니까? (0) | 2023.07.28 |
| 다른 뷰에서 뷰 작성 (0) | 2023.07.28 |
| 도커 컨테이너 및 mysql 워크벤치 내의 MariaDb에 대한 연결 (0) | 2023.07.28 |
| 배열 항목 대신 완전 배열 개체를 한 번에 하나씩 파이프로 연결하시겠습니까? (0) | 2023.07.28 |