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

(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를 공개적으로 확장 할 수 있습니다.

I do not like the 'impl' or 'support' names, but they help separate the less important stuff from the important (domain and API). When it comes to naming I like to be as concrete as possible. If you have a package called 'utils' with 20 classes, move StringUtils to support/string, HttpUtil to support/http and so on.

---

Are there best practices with regards to the organisation of packages in Java and what goes in them?

Not really no. There are lots of ideas, and lots opinions, but "best practice" is to use your common sense!

However, there is one principal that probably has broad acceptance. Your package structure should reflect your application's (informal) module structure, and you should aim to minimize (or ideally entirely avoid) any cyclic dependencies between modules.

(Cyclic dependencies between classes in a package / module are just fine, but inter-package cycles tend to make it hard understand your application's architecture, and can be a barrier to code reuse. In particular, if you use Maven you will find that cyclic inter-package / inter-module dependencies mean that the whole interconnected mess has to be one Maven artifact.)

I should also add that there is one widely accepted best practice for package names. And that is that your package names should start with your organization's domain name in reverse order. If you follow this rule, you reduce the likelihood of problems caused by your (full) class names clashing with other peoples'.

---

I've seen some people promote 'package by feature' over 'package by layer' but I've used quite a few approaches over many years and found 'package by layer' much better than 'package by feature'.

Further to that I have found that a hybrid: 'package by module, layer then feature' strategy works extremely well in practice as it has many advantages of 'package by feature':

• Promotes creation of reusable frameworks (libraries with both model and UI aspects)
• Allows plug and play layer implementations - virtually impossible with 'package by feature' because it places layer implementations in same package/directory as model code.
• Many more...

I explain in depth here: Java Package Name Structure and Organization but my standard package structure is:

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

Where:

revdomain Reverse domain e.g. com.mycompany

moduleType [app*|framework|util]

moduleName e.g. myAppName if module type is an app or 'finance' if its an accounting framework

layer [model|ui|persistence|security etc.,]

layerImpl eg., wicket, jsp, jpa, jdo, hibernate (Note: not used if layer is model)

feature eg., finance

subfeatureN eg., accounting

subfeatureN+1 eg., depreciation

*Sometimes 'app' left out if moduleType is an application but putting it in there makes the package structure consistent across all module types.

---

I'm not aware of standard practices for package organization. I generally create packages that cover some reasonably broad spectrum, but I can differentiate within a project. For example, a personal project I'm currently working on has a package devoted to my customized UI controls (full of classes subclassing swing classes). I've got a package devoted to my database management stuff, I've got a package for a set of listeners/events that I've created, and so on.

On the other hand I've had a coworker create a new package for almost everything he did. Each different MVC he wanted got its own package, and it seemed a MVC set was the only grouping of classes allowed to be in the same package. I recall at one point he had 5 different packages that each had a single class in them. I think his method is a little bit on the extreme (and the team forced him to reduce his package count when we simply couldn't handle it), but for a nontrivial application, so would putting everything in the same package. It's a balance point you and your teammates have to find for yourself.

One thing you can do is try to step back and think: if you were a new member introduced to the project, or your project was released as open source or an API, how easy/difficult would it be to find what you want? Because for me, that's what I really want out of packages: organization. Similar to how I store files in folder on my computer, I expect to be able to find them again without having to search my entire drive. I excpect to be able to find the class I want without having to search the list of all classes in the package.

참고URL : https://stackoverflow.com/questions/3226282/are-there-best-practices-for-java-package-organization