Por qué deberías evitar el ámbito package-private en Java
Recientemente estuve discutiendo en mi proyecto sobre el modificador de visibilidad package-private.
«Espera, ¿qué es package-private en Java?». También se llama a veces por defecto o sin modificador.
Esto es cuando la clase o método no tiene ningún modificador. Por ejemplo:
class SomeObject { void doSomething() { ... }}Hay más detalles en el tutorial de Java.
No debería usarse a menos que haya una razón muy específica. Puedes elegir entre público, privado o protegido.
Hay razones que he escuchado hasta ahora de diferentes personas:
- ¡Pero lo necesito para probar el método en mi objeto!
- ¡Pero es mejor restringir el acceso al objeto tanto como sea posible! Es accedido sólo por las clases del mismo paquete.
- ¡Tengo una biblioteca con muchos usuarios y quiero ocultar los detalles de la implementación de ellos!
¡Pero lo necesito para probar el método en mi objeto!
No hagas package-private sólo para probar ese método tan importante. Es una de las falacias frecuentes que observo. La gente tiende a acceder de alguna manera a esa lógica privada, la relaja un poco y luego hace pruebas sucias!
Hay una manera mejor. Primero tienes que entender que algo probablemente está mal en tu diseño, si hay una funcionalidad oculta que es difícil de probar. Esto significa que es un candidato perfecto para la refactorización. Simplemente extrae esa lógica en una clase interna con métodos de API bien definidos y pruébalos. ¡
Pero es mejor restringir el acceso al objeto tanto como sea posible! Sólo se accede a él por las clases del mismo paquete.
La documentación oficial de Oracle dice:Use the most restrictive access level that makes sense for a particular member.
Use private unless you have a good reason not to.
Estoy totalmente de acuerdo con esta afirmación, sólo si eliminamos package-private de esta lista. La vida será mucho más fácil para su proyecto si todo será público/privado. Una de las refactorizaciones más frecuentes en grandes bases de código es Move File/Class. Con muchos paquetes de acceso privado se volverá inmediatamente molesto hacerlo. ¿Por qué no hacerlos públicos entonces?
Al final tanto los públicos como los privados exponen la API de tu clase. No importa que en este último caso esté limitado por el paquete, sigue siendo una API de la que tienes que preocuparte.
- Pruebas. Es una tendencia relativamente nueva el no escribir modificadores de acceso para el código de prueba. De todas formas los modificadores aportan algo de ruido al código y la visibilidad del acceso no importa tanto en las pruebas como en el código de producción. Menos tipificación es mejor!
- Estás soportando una librería con muchos usuarios. ¡A menos que su biblioteca debe ser compatible con java8 o menos! Si no, te animo a usar JPMS (Project Jigsaw) en tus librerías, que te dará mucho mejor control sobre tus API’s expuestas y la implementación interna en comparación con package-private
Así que como puedes ver en 2019 (¡pronto 2020!) no hay tantas razones para ir con la visibilidad package-private.