(Java) 패키지 구성에 대한 모범 사례가 있습니까? [닫은]

얼마 전, 세밀한 자바 패키지 구성에 관한 질문에 답했습니다. 예를 들어, my.project.util, my.project.factory, my.project.service등과

나는 지금 그것을 찾을 수 없으므로 질문을 할 수도 있습니다.

Java 패키지 구성과 관련하여 모범 사례가 있습니까?

Java 프로젝트에서 클래스를 어떻게 구성합니까?

예를 들어, 소수의 사람들과 함께 작업하는 프로젝트에는 bean이라는 패키지가 있습니다. 간단한 콩을 포함하는 프로젝트로 시작되었지만 (거의) 모든 것을 포함하는 (빈약 한 경험과 시간 부족으로) 끝났습니다. 팩토리 패키지 (빈을 생성하는 정적 메소드가있는 클래스)에 팩토리 클래스를 넣어서 약간 정리했지만 비즈니스 로직을 수행하는 다른 클래스와 검색과 같은 간단한 처리 (비즈니스 로직이 아닌)를하는 다른 클래스가 있습니다. 특성 파일의 코드에 대한 메시지

당신의 생각과 의견에 감사드립니다.

패키지 구성 또는 패키지 구조화는 일반적으로 열띤 토론입니다. 다음은 패키지 이름 지정 및 구조화에 대한 간단한 지침입니다.

• 자바 패키지 명명 규칙 준수
• 기능적 역할 및 비즈니스 역할에 따라 패키지 구성
  • 기능 또는 모듈에 따라 패키지를 분류하십시오. 예 : com.company.product.modulea
  • 추가 분류는 소프트웨어의 계층을 기반으로 할 수 있습니다. 그러나 패키지에 클래스가 거의없는 경우에는 배 안에 가지 마십시오. 패키지에 모든 것이있는 것이 좋습니다. 예를 들어, com.company.product.module.web또는 com.company.product.module.util등
  • 구조화를하지 말고, IMO는 긴급한 요구가없는 한 예외, 공장 등을 위해 별도의 포장을 피하십시오.
• 프로젝트가 작은 경우 몇 개의 패키지로 간단하게 유지하십시오. 예를 들어 com.company.product.model및 com.company.product.util등
• Apache 프로젝트 에서 널리 사용되는 오픈 소스 프로젝트 중 일부를 살펴보십시오 . 다양한 규모의 프로젝트에 대해 구조화를 사용하는 방법을 확인하십시오.
• 이름을 지정할 때 빌드 및 배포도 고려하십시오 (API 또는 SDK를 다른 패키지로 배포 할 수 있습니다 (서블릿 API 참조)).

몇 가지 실험과 시험을 마치고 나면 편안한 구조를 만들 수있을 것입니다. 하나의 규칙으로 고치지 말고 변경 사항을 공개하십시오.

패턴이나 구현 역할이 아닌 기능별로 패키지 를 구성 합니다. 패키지는 다음과 같습니다.

• beans
• factories
• collections

잘못되었습니다.

예를 들어 선호합니다.

• orders
• store
• reports

패키지 가시성을 통해 구현 세부 사항을 숨길 수 있습니다 . 주문 팩토리는 orders패키지에 있어야하므로 주문 작성 방법에 대한 세부 사항이 숨겨집니다.

짧은 답변 : 모듈 / 기능 당 하나의 패키지 (하위 패키지 포함). 밀접하게 관련된 것들을 같은 패키지에 넣습니다. 패키지 간의 순환 종속성을 피하십시오.

긴 대답 : 이 기사의 대부분에 동의합니다

레이어보다 기능을 선호하지만 프로젝트에 따라 다릅니다. 당신의 힘을 고려하십시오 :

• 종속성
  특히 기능 간의 패키지 종속성을 최소화하십시오. 필요한 경우 API를 추출하십시오.
• 팀 구성
  일부 조직에서 팀은 기능에 대해 작업하고 다른 조직 에서는 계층에 대해 작업합니다. 이는 코드 구성 방식에 영향을 미치며이를 사용하여 API를 공식화하거나 협력을 장려합니다.
• 배포 및 버전 관리
  모듈에 모든 것을 넣으면 배포 및 버전 관리가 간단 해지지 만 버그 수정이 더 어려워집니다. 분할하면 제어, 확장 성 및 가용성이 향상됩니다.
• 변화에 대응하기
  잘 조직 된 코드는 큰 진흙 공보다 변경하기가 훨씬 간단합니다.
• 크기 (사람과 코드 줄)
  더 형식화 / 표준화되어야합니다.
• 중요성 / 품질
  일부 코드는 다른 코드보다 중요합니다. API는 구현보다 안정적이어야합니다. 따라서 명확하게 분리해야합니다.
• 추상화 수준과 진입 점
  외부인이 코드의 내용과 패키지 트리를보고 읽을 위치를 알 수 있어야합니다.

예:

com/company/module
  + feature1/
    - MainClass          // The entry point for exploring
    + api/               // Public interface, used by other features
    + domain/
      - AggregateRoot
      + api/             // Internal API, complements the public, used by web
      + impl/ 
    + persistence/       
    + web/               // presentation layer 
    + services/          // Rest or other remote API 
    + support/            
  + feature2/
  + support/             // Any support or utils used by more than on feature
    + io
    + config
    + persistence
    + web

이것은 단지 예일뿐입니다. 꽤 형식적입니다. 예를 들어 feature1에 대해 2 개의 인터페이스를 정의합니다 . 일반적으로 필요하지는 않지만 다른 사람들이 다르게 사용하는 경우 좋은 아이디어가 될 수 있습니다. 내부 API를 공개적으로 확장 할 수 있습니다.

나는 'impl'또는 'support'이름을 좋아하지 않지만 덜 중요한 것들을 중요한 것 (도메인 및 API)과 분리하는 데 도움이됩니다. 명명에 관해서는 가능한 한 구체적이고 싶습니다. 20 개의 클래스가있는 'utils'라는 패키지가있는 경우 StringUtilssupport / string, HttpUtilsupport / http 등으로 이동하십시오.

Java 패키지 구성과 관련하여 모범 사례가 있습니까?

아니에요 많은 아이디어와 의견이 있지만 실제 "모범 사례"는 상식을 사용하는 것입니다!

( "모범 사례"및이를 홍보하는 사람들에 대한 관점은 모범 사례 없음을 읽으십시오 .)

그러나 널리 받아 들여질 수있는 한 가지 원칙이 있습니다. 패키지 구조는 애플리케이션의 (비공식적 인) 모듈 구조를 반영해야하며, 모듈 간의 주기적 종속성을 최소화 (또는 이상적으로는 피)하는 것이 목표입니다.

(패키지 / 모듈의 클래스 간 순환 종속성은 훌륭하지만 패키지 간 사이클은 응용 프로그램의 아키텍처를 이해하기 어렵게 만들고 코드 재사용에 장애가 될 수 있습니다. 특히 Maven을 사용하면 주기적으로 패키지 간 / 모듈 간 종속성은 상호 연결된 전체 엉망이 하나의 Maven 인공물이어야 함을 의미합니다.)

또한 패키지 이름에 대해 널리 인정되는 모범 사례 가 하나 더 있다고 덧붙여 야 합니다. 즉, 패키지 이름은 조직의 도메인 이름으로 역순으로 시작해야합니다. 이 규칙을 따르면, 다른 사람들과 충돌하는 (전체) 학급 이름으로 인한 문제의 가능성이 줄어 듭니다.

일부 사람들이 '레이어 별 패키지'보다 '기능별 패키지'를 홍보하는 것을 보았지만 몇 년 동안 상당히 많은 접근 방식을 사용했으며 '피처 별 패키지'보다 '레이어 별 패키지'가 훨씬 낫습니다.

또한 '패키지 별 패키지'의 많은 장점이 있기 때문에 하이브리드 : '모듈 별 패키지, 레이어 및 기능'전략이 실제로 매우 효과적이라는 것을 알았습니다.

• 재사용 가능한 프레임 워크 생성을 촉진합니다 (모델 및 UI 측면을 모두 갖춘 라이브러리)
• 플러그 앤 플레이 레이어 구현을 허용합니다. '패키지 별 기능'에서는 모델 구현과 동일한 패키지 / 디렉토리에 레이어 구현을 배치하므로 사실상 불가능합니다.
• 더 많은 ...

여기서 자세히 설명합니다 : Java 패키지 이름 구조 및 구성 하지만 표준 패키지 구조는 다음과 같습니다.

revdomain.moduleType.moduleName.layer. [layerImpl] .feature.subfeatureN.subfeatureN + 1 ...

어디:

revdomain 역 도메인 예 : com.mycompany

moduleType [app * | framework | util]

moduleName 예 : 모듈 유형이 앱인 경우 myAppName 또는 회계 프레임 워크 인 경우 '금융'

층 [유형 등]

layerImpl . 예를 들어, 개찰구는, JSP로, JPA는 JDO는 (주 : 사용하지 않는 계층이 모델의 경우) 최대 절전 모드

특징, 예 : 금융

하위 기능 예 : 회계

하위 기능 N + 1, 예 : 감가 상각

* moduleType이 응용 프로그램 인 경우 'app'가 누락되었지만 응용 프로그램을 넣으면 모든 모듈 유형에서 패키지 구조가 일관되게됩니다.

패키지 구성에 대한 표준 사례를 모릅니다. 나는 일반적으로 상당히 넓은 스펙트럼을 다루는 패키지를 만들지 만 프로젝트 내에서 차별화 할 수 있습니다. 예를 들어, 현재 작업중 인 개인 프로젝트에는 맞춤형 UI 컨트롤 (스위스 클래스를 스윙하는 클래스로 가득 찬)에 전용 패키지가 있습니다. 데이터베이스 관리에 전념하는 패키지가 있고, 내가 만든 리스너 / 이벤트 집합에 대한 패키지가 있습니다.

다른 한편으로 나는 동료가 자신이 한 거의 모든 것을위한 새로운 패키지를 만들도록했습니다. 그가 원하는 각각의 다른 MVC는 자체 패키지를 가지고 있었고 MVC 세트는 동일한 패키지에있을 수있는 유일한 클래스 그룹 인 것처럼 보였습니다. 한 시점에서 그는 각각 하나의 클래스를 가진 5 개의 서로 다른 패키지를 가지고있었습니다. 나는 그의 방법이 극단적이라고 생각합니다 (그리고 팀은 단순히 처리 할 수 ​​없을 때 패키지 수를 줄 이도록 강요했습니다). 그러나 사소한 응용 프로그램의 경우 모든 것을 동일한 패키지에 넣을 것입니다. 그것은 당신과 당신의 팀원이 스스로 찾아야 할 균형점입니다.

한 가지 뒤로 물러서서 생각해보십시오. 프로젝트에 신입 사원을 소개했거나 프로젝트가 오픈 소스 또는 API로 출시 된 경우 원하는 것을 찾기가 얼마나 쉬울까요? 나에게있어서 그것이 바로 패키지에서 원하는 것입니다 : 조직. 컴퓨터의 폴더에 파일을 저장하는 방법과 마찬가지로 전체 드라이브를 검색하지 않고도 파일을 다시 찾을 수있을 것으로 기대합니다. 패키지의 모든 클래스 목록을 검색하지 않고도 원하는 클래스를 찾을 수있을 것으로 예상됩니다.