visibility - inner - paquete de alternativa protegida en kotlin

sealed in kotlin

Question

En java tenemos el modificador protegido por paquete (por defecto) para las clases, lo que permite tener muchas clases en un solo paquete pero exponer pocas y mantener la lógica encapsulada.

Con kotlin, este no parece ser el caso, si quiero tener algunas otras clases que sean visibles entre sí pero no más, tengo que usar un modificador privado que limita la visibilidad a un solo archivo ... así que esencialmente si tuvieras 10 las clases en un paquete y solo una de ellas era pública, ahora tendrá un archivo enorme con todas las clases (y private todo el lugar) ...

¿Es esta práctica normal o hay una manera de lograr la modularidad similar en kotlin?

No entiendo si tienen noción de paquete por qué se deshicieron del acceso protegido del paquete ...

Actualización: podemos tener visibilidad protegida del paquete después de todo
mira la discusión aquí

Answer 1

Como señala @hotkeys, puede usar la palabra clave internal en un module . Normalmente trabajo con eclipse y maven y no es práctico para mí crear estos módulos.

Tal vez para una pila de tecnología diferente con IDEA o Gradle es más práctico; No lo sé porque nunca los utilicé.

La otra opción es poner todas las clases de un paquete dentro de un solo archivo. Esto no siempre es práctico o elegante.

Para mí, la visibilidad del package es extremadamente útil para su valor de documentación. Quiero saber qué interfaz pública está presentando algún paquete para el resto del proyecto. Quiero ocultar las clases de implementaciones de fábrica, etc.

Entonces, incluso si es posible abrirse camino en Java para clases y métodos privados, me gusta utilizar la palabra clave package .

Lo que hice fue crear un proyecto con una sola anotación:

package com.mycompany.libraries.kotlinannotations;
import static java.lang.annotation.ElementType.CONSTRUCTOR;
import static java.lang.annotation.ElementType.METHOD;
import static java.lang.annotation.ElementType.TYPE;
import static java.lang.annotation.RetentionPolicy.SOURCE;
import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
@Documented
@Retention(SOURCE)
@Target({ TYPE, METHOD, CONSTRUCTOR })
/**
* Use in Kotlin code for documentation purposes.
*
* Whenever a Kotlin class or method is intended to be accesible at package level only.
*
*/
public @interface PackagePrivate {
}

Entonces puedo usar esta anotación en cualquier proyecto de Kotlin.

El segundo paso, que todavía no he logrado, y me gustaría hacer en algún momento, es crear una regla PMD para aplicar esto con maven (o cualquier otra herramienta de compilación para ese caso) y también poder ver violaciones de la regla en mi IDE con el plugin pmd.

Por el momento, Kotlin aún no es uno de los idiomas admitidos por pmd (es decir, con su propio módulo). Pero el PMD está en desarrollo activo y Kotlin está ganando popularidad, por lo que existe la posibilidad de que se desarrolle en algún momento. Esa es solo mi mejor suposición.

Answer 2

Kotlin, en comparación con Java, parece confiar en el modelo de paquetes en menor grado (por ejemplo, la estructura de los directorios no está vinculada a los paquetes). En cambio, Kotlin ofrece visibilidad internal , que está diseñada para la arquitectura de proyectos modulares. Utilizándolo, puede encapsular una parte de su código dentro de un module separado.

Por lo tanto, en las declaraciones de nivel superior puede usar

• private para restringir la visibilidad del archivo
• internal para restringir la visibilidad del módulo

En este punto, no hay otra opción para la restricción de visibilidad.