Estrutura de pacotes para um projeto Java?

116

Qual é a prática recomendada para configurar estruturas de pacote em um aplicativo da Web Java?

Como você configuraria seu src, código de teste de unidade, etc?

java packages

— mawaldne
fonte

95

Você pode seguir o layout de projeto padrão do maven . Você não precisa realmente usar o maven, mas isso tornaria a transição mais fácil no futuro (se necessário). Além disso, outros desenvolvedores estarão acostumados a ver esse layout, uma vez que muitos projetos de código aberto são dispostos desta forma,

— johnstok
fonte

2

Eu também recomendo usar o layout do Maven se você tiver escolha. É uma estrutura bem pensada que foi testada em batalha e é familiar para muitos desenvolvedores.

— Dov Wasserman

15

Você pode usar este oneliner para criar o layout do diretório: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Daniel Hepper

1

O layout de projeto padrão do Maven é feio ...: /

— Yousha Aleayoub

2

@YoushaAleayoub você não precisa se casar com ele

— Ashvin Sharma

59

Existem alguns recursos existentes que você pode verificar:

Pelo que vale a pena, minhas próprias diretrizes pessoais que costumo usar são as seguintes:

Comece com o domínio reverso, por exemplo, "com.minhaempresa".
Use o nome do produto, por exemplo, "meu produto". Em alguns casos, minha tendência é ter pacotes comuns que não pertencem a um produto específico. Eles acabariam categorizados de acordo com a funcionalidade dessas classes comuns, por exemplo, "io", "util", "ui", etc.
Depois disso, torna-se mais livre. Normalmente eu agrupo de acordo com o projeto, área de funcionalidade, implantação, etc. Por exemplo, posso ter "projeto1", "projeto2", "ui", "cliente", etc.

Alguns outros pontos:

É bastante comum em projetos em que trabalhei que os nomes dos pacotes fluam da documentação de design. Normalmente, os produtos já são separados em áreas de funcionalidade ou finalidade.
Não se estresse muito em colocar funcionalidades comuns em pacotes superiores imediatamente. Espere até que haja uma necessidade entre projetos, produtos, etc. e, em seguida, refatorar.
Observe as dependências entre pacotes. Eles não são todos ruins, mas podem significar um acoplamento estreito entre o que podem ser unidades separadas. Existem ferramentas que podem ajudá-lo a controlar isso.

— Lycono
fonte

2

No caso de domínio reverso ("com.mycompany"), o pacote "com" geralmente está vazio, exceto para o subpacote "mycompany"?

— Alex Parker

45

Eu sugeriria criar sua estrutura de pacote por recurso, e não pela camada de implementação. Uma boa descrição disso são as práticas Java: pacote por recurso, não por camada

— analista de informações
fonte

2

Obrigado. Isso é o que eu estava procurando para transmitir minhas idéias à equipe

— Pranalee

8

E se você deseja trocar de banco de dados? Basta procurar em 30 embalagens diferentes. Mover de SFTP para serviços da web? Novamente, basta olhar em 30 lugares diferentes. Definitivamente não é um fã.

— SamuelKDavis

1

outro exemplo onde o empacotamento por camada tem benefícios: se você serializar classes para JSON (por exemplo, com gson), se essas classes forem ofuscadas (por exemplo, por Proguard) (a des) serialização irá falhar; você precisa configurar o Proguard para não tocar nessas classes - é mais fácil apenas especificar um único pacote com todas elas

— jmuet

6

Normalmente gosto de ter o seguinte:

bin (binários)
doc (documentos)
inf (informações)
lib (bibliotecas)
res (recursos)
src (fonte)
tst (teste)

Podem ser considerados não convencionais, mas acho que é uma maneira muito boa de organizar as coisas.

"Estes podem ser considerados não convencionais" Eles são realmente não convencionais e ruins, a propósito ...

— mahieddine

2

@mahieddine Por que você os considera ruins?

— Thomas Johannesmeyer

Bem, não fui eu quem disse isso, mas aqui estão alguns dos meus pensamentos: Suas classes de teste são o código-fonte, então o diretório "tst" (a maioria das pessoas não abrevia test btw) deve ser um subdiretório de src (por exemplo, " src "torna-se" src / main "e" tst "torna-se" src / test "). Além disso, "inf" parece incluir conteúdo que pode estar em "doc".

— Nico Wawrzyniak

6

The way I usually organise is
- src
        - main
                - java
                - groovy
                - resources
        - test
                - java
                - groovy
- lib
- build
        - test 
                - reports
                - classes
- doc

— Raj
fonte

3

A maneira como geralmente tenho minha hierarquia de pastas

Nome do Projeto
- src
- bin
- testes
- libs
- docs

— PDeva
fonte

1

Outra maneira é separar as APIs, serviços e entidades em pacotes diferentes.

— Deepak Patankar
fonte