package de alternativa protegida en kotlin

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

Con kotlin, este no parece ser el caso, si quiero tener algunas otras classs que sean visibles entre sí pero no más, tengo que usar un modificador privado que limita la visibilidad a un solo file … así que esencialmente si tuvieras 10 las classs en un package y solo una de ellas era pública, ahora tendrá un file enorme con todas las classs (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 package por qué se deshicieron del acceso protegido del package …

Kotlin, en comparación con Java, parece confiar en el model de packages en menor grado (por ejemplo, la estructura de los directorys no está vinculada a los packages). En cambio, Kotlin ofrece visibilidad internal , que está diseñada para la architecture 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 file
  • internal para restringir la visibilidad del module

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

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

Tal vez para una stack 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 classs de un package dentro de un solo file. Esto no siempre es práctico o elegante.

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

Entonces, incluso si es posible abrirse path en Java para classs y methods privados, me gusta utilizar la palabra key 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 compilation 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 module). 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 suposition.