Convenciones de nomenclatura y organización de paquetes

7

He estado programando en Java, C #, Python y AS3 la mayoría del tiempo y en todos estos lenguajes hay paquetes (o algo así). El problema que encontré es con la convención de nombres, o incluso con la organización de los paquetes. Necesito que alguien me diga POR QUÉ es esto:

com.company.app.type.Object o org.authorname.project.type.Object

mejor que esto:

app.feature.Object o app.module.Object

Otro ejemplo:

Por qué esto:

com
 +--company
     +--app
         +--events
         |   |--FeatureOneEventA
         |   |--FeatureOneEventB
         |   |--FeatureOneEventC
         |   |--FeatureTwoEventA
         |   |--FeatureTwoEventB
         |   
         +--models
         |   |--FeatureOne
         |   |--FeatureTwo
         |   
         +--services
             |--FeatureOneServiceA
             |--FeatureTwoServiceA
             |--FeatureTwoServiceB

Es "mejor" que esto:

 company
  +--app
      +--feature
          +--one
          |   |--Model
          |   |
          |   +--events
          |   |   |--EventA
          |   |   |--EventB
          |   |   |--EventC
          |   |
          |   +--services
          |       |--ServiceA
          |  
          +--two
              |--Model
              |
              +--events
              |   |--EventA
              |   |--EventB
              |
              +--services
                  |--ServiceA
                  |--ServiceB

En el primero, todos están organizados por "tipos de objetos", pero las "características" están todas mezcladas, pero en el segundo, la organización es por "característica" y cada una tiene sus propios objetos; así, puedes ver una característica bien separada de otra.

Entonces, ¿alguien puede decirme por qué muchas empresas y programadores prefieren la primera?

    
pregunta Lucas Gabriel Sánchez 18.08.2011 - 20:43

4 respuestas

5

La razón para tener su nombre de dominio inverso como el principio de un nombre de paquete es reducir la posibilidad de conflictos de nombres. Esto es especialmente importante si está escribiendo una biblioteca o un marco. Así que eso explica por qué "com" y "org" están ahí.

Aparte de eso, cada persona es diferente y elige su estructura de paquetes de manera diferente. Una razón por la que la opción 1 podría ser mejor es si no hay una distinción real entre las funciones o si tienen una gran cantidad de código que se cruza. Con eso, la opción 2 podría tener más sentido si las características realmente se excluyen mutuamente de alguna manera.

También, apuesto a que la opción 1 es generalmente la forma en que comienzan la mayoría de los proyectos, y luego nadie la cambia (o le importa) después. No me sorprendería que muchas compañías no reflexionen sobre la estructura de su paquete de todos modos.

    
respondido por el Jeremy Heiler 18.08.2011 - 20:53
2

De acuerdo con los demás, el prefijo del paquete es el dominio de la empresa.

En el segundo punto, generalmente elijo los nombres de paquetes como usted sugiere, por característica antes de por tipo de archivo (como escribió, a menudo se elige la otra política).

Tenga en cuenta que el código técnico (como StringHelper o MenuInterceptor) no es directamente una función, por lo que no sigue las mismas convenciones.

Lo prefiero porque:

  • al trabajar en una función, puede encontrar fácilmente el código correspondiente
  • puede hacer uso de la visibilidad package (intermedio entre una clase interna privada y una clase realmente pública).
  • puede iniciar pruebas automáticas para verificar completamente una función (es lo que le importa a su cliente; y también es lo que podría romperse cuando modifica el código antiguo)
  • si un proyecto normalmente tiene características pequeñas con pocas clases, o muchas clases opcionales que no siempre son necesarias, los subdirectorios podrían no ser necesarios, todas las clases pueden estar contenidas en el mismo paquete (y el sufijo indica qué rol desempeña esa clase en la característica).

Por cierto, creo que varias características no suelen compartir mucho código. Si un código es reutilizable, es:

  • en una capa diferente (como código técnico), completamente en otra parte (tal vez no en el mismo proyecto Java)
  • en una superclase (el código común puede usar paquetes como lo hacen las características)
respondido por el KLE 29.08.2011 - 21:18
1

Por lo que he visto, el primero es común en Java y sus parientes (ActionScript, por ejemplo). No sé muy bien por qué, pero supongo que tiene que ver con evitar cualquier posible conflicto de nombres.

C # y .NET en general, así como creo que Python, prefiere el segundo estilo. De hecho, las directrices de .NET desalientan expresamente el estilo de Java y recomiendan: CompanyName.ApplicationName.ModuleName.LogicalGroup para el ejemplo Cyberdyne.Skynet.SelfDefense.CyborgActivation

    
respondido por el Wayne Molina 29.08.2011 - 21:33
0

Bueno, el primero es por pura convención. En la especificación de Java, se recomienda que los paquetes se nombren como el reverso del nombre de dominio de su empresa, ya que eso garantizaría la exclusividad. Esa es la razón por la que los paquetes de Java se llaman así. C ++ y C #, y por lo tanto .NET, siguen la convención de espacio de nombres que ha existido durante años. No creo que ninguna de estas formas sea intrínsecamente mejor que ninguna otra, es solo la forma en que los idiomas evolucionaron.

    
respondido por el Jonathan Henson 18.08.2011 - 20:54

Lea otras preguntas en las etiquetas