Cómo usar el modificador de acceso Java correctamente en el desarrollo de la biblioteca

Question

Estoy desarrollando una biblioteca que el otro programador importará y usará para sus propósitos.

Estoy confundido acerca del objetivo del modificador de acceso Java.

El problema es que no tengo clases inferiores

• ClassA en el paquete org.mylibrary
• ClassB en el paquete org.mylibrary.internal

claseA necesita resolver de manera ClassB ClassB tiene por qué ser clase pública.

Sin embargo, desde la vista del usuario de la biblioteca, no pretendo que ClassB sea visible fuera de mi biblioteca. Porque no debe ser ni debe ser iniciado por el usuario.

Creo que mover ClassB al paquete org.mylibrary y convertirlo en una clase package-private.

Si lo muevo al mismo paquete, sería un desastre y difícil de organizar porque tengo muchas clases en este escenario, por lo que habrá muchos archivos .java en un gran paquete.

Normalmente pongo las clases en paquetes agrupados por categoría o capa y creo que es fácil de organizar.

¿Cómo puedo hacer esto? ¿Cómo manejan las personas este problema?

Answer 1

Es difícil dar consejos concretos dado que se proporciona muy poca información sobre los roles y la relación entre ClassA y . Sin embargo, una solución general (que casi siempre se utiliza como parte de la eliminación de dependencias) es ocultar ClassB detrás de una interfaz. Luego, ClassA usa solo esa interfaz, por lo que ya no depende directamente de ClassB. ClassB se pueden hacer paquetes privados, sus instancias producidas por ej. a factory, o dependency injected en ClassA.

Answer 2

Suponiendo ClassB es un paquete de prueba con pruebas unitarias:

¿Por qué ClassB necesidad de usarlo. Normalmente las clases de prueba usan las clases regulares, no al revés.

En general, la recomendación para las clases de prueba es para ponerlos en el mismo paquete como las clases regulares, pero mantener los archivos .java en una jerarquía de directorios en paralelo (es decir, usted tiene src/org/miempresa/MiClase. java, y test-src/org/mycompany/MyClassTest.java). De esta forma, para Java ambos están en el mismo paquete y pueden tener acceso el uno al otro, y para las versiones de lanzamiento simplemente no compilas las clases de prueba (o ni siquiera las revisas); de esa forma todo está muy bien separado.

Si esto no se aplica en su caso, ¿podría editar su pregunta con más detalle?

Answer 3

sería un lío y difícil de organizar porque tengo muchas clases en este escenario.

¿Quiere decir que el archivo java parece desordenado? Puede dividir las clases internas en un archivo .java diferente.

ClassA.java

package org.application; 

public class ClassA { 
} 

Internal.java

package org.application; 

class ClassB { 
} 

class SomeOtherInternalClass { 
} 

Espero que esto ayude.

Answer 4

Creo que entiendo su pregunta, ¡y la respuesta es que no hay manera de hacerlo en java hasta ahora!

hay algunas formas complicadas pero implican la codificación suciedad.

mira aquí

http://openide.netbeans.org/tutorial/api-design.html#design.less.friend