¿Estructura de paquete para un proyecto Java?

116

¿Cuál es la mejor práctica para configurar estructuras de paquetes en una aplicación web Java?

¿Cómo configurarías tu src, código de prueba de unidad, etc.?

java packages

— Mawaldne
fuente

95

Puede seguir el diseño de proyecto estándar de maven . No es necesario que utilice maven, pero facilitaría la transición en el futuro (si fuera necesario). Además, otros desarrolladores estarán acostumbrados a ver ese diseño, ya que muchos proyectos de código abierto se presentan de esta manera,

— Johnstok
fuente

2

También recomiendo usar el diseño de Maven si tiene la opción. Es una estructura bien pensada que ha sido probada en batalla y es familiar para muchos desarrolladores.

— Dov Wasserman

15

Puedes usar este delineador para crear el diseño del directorio: mkdir -p src / {main / {java, resources, filters, assembly, config, webapp}, test / {java, resources, filters}, site}

— Daniel Hepper

1

El diseño estándar del proyecto de Maven es feo ...: /

— Yousha Aleayoub

2

@YoushaAleayoub no tienes que casarte con él

— Ashvin Sharma

59

Hay algunos recursos existentes que puede consultar:

Por lo que vale, mis propias pautas personales que suelo usar son las siguientes:

Comience con dominio inverso, por ejemplo, "com.miempresa".
Utilice el nombre del producto, por ejemplo, "myproduct". En algunos casos, tiendo a tener paquetes comunes que no pertenecen a un producto en particular. Estos terminarían categorizados de acuerdo con la funcionalidad de estas clases comunes, por ejemplo, "io", "util", "ui", etc.
Después de esto, se vuelve más libre. Por lo general, agrupo de acuerdo con el proyecto, área de funcionalidad, implementación, etc. Por ejemplo, podría tener "proyecto1", "proyecto2", "ui", "cliente", etc.

Un par de otros puntos:

Es bastante común en los proyectos en los que he trabajado que los nombres de los paquetes fluyan de la documentación de diseño. Por lo general, los productos ya están separados en áreas de funcionalidad o propósito.
No se preocupe demasiado por llevar la funcionalidad común a paquetes superiores de inmediato. Espere a que haya una necesidad en proyectos, productos, etc., y luego refactorice.
Observe las dependencias entre paquetes. No son del todo malos, pero pueden significar un acoplamiento estrecho entre lo que podrían ser unidades separadas. Existen herramientas que pueden ayudarlo a realizar un seguimiento de esto.

— lycono
fuente

2

En el caso del dominio inverso ("com.mycompany"), ¿el paquete "com" normalmente está vacío, excepto el subpaquete "mycompany"?

— Alex Parker

45

Sugeriría crear la estructura de su paquete por característica, y no por la capa de implementación. Una buena reseña sobre esto son las prácticas de Java: paquete por característica, no capa

— analista de datos
fuente

2

Gracias. Esto es lo que estaba buscando para transmitir mis pensamientos al equipo

— Pranalee

8

¿Y si desea cambiar de base de datos? Solo hay que buscar en 30 paquetes diferentes. ¿Pasar de SFTP a servicios web? Nuevamente solo hay que buscar en 30 lugares diferentes. Definitivamente no soy un fan.

— SamuelKDavis

1

otro ejemplo donde el empaquetado por capa tiene beneficios: si serializa clases a JSON (por ejemplo, con gson), si esas clases están ofuscadas (por ejemplo, por Proguard), la (des) serialización fallará; necesita configurar Proguard para que no toque tales clases; es lo más fácil especificar un solo paquete con todas ellas

— jmuet

6

Normalmente me gusta tener lo siguiente:

bin (binarios)
doc (documentos)
inf (información)
lib (Bibliotecas)
res (Recursos)
src (fuente)
tst (prueba)

Estos pueden considerarse poco convencionales, pero me parece una forma muy agradable de organizar las cosas.

"Estos pueden considerarse poco convencionales" Por cierto, son poco convencionales y malos ...

— mahieddine

2

@mahieddine ¿Por qué los consideras malos?

— Thomas Johannesmeyer

Bueno, no fui yo quien dijo eso, pero aquí están algunos de mis pensamientos: Sus clases de prueba son código fuente, por lo que el directorio "tst" (la mayoría de las personas no abrevian test por cierto) debería ser un subdirectorio de src (por ejemplo, " src "se convierte en" src / main "y" tst "se convierte en" src / test "). También "inf" parece incluir contenido que podría estar en "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
fuente

3

La forma en que suelo tener mi jerarquía de carpetas

Nombre del proyecto
- src
- compartimiento
- pruebas
- libs
- docs

— pdeva
fuente

1

Otra forma es separar las API, los servicios y las entidades en diferentes paquetes.

— Deepak Patankar
fuente