Подтвердить что ты не робот

Альтернатива, защищенная пакетом в котлин

В java у нас есть защищенный от пакета (по умолчанию) модификатор для классов, который позволяет иметь много классов в одном пакете, но показывать только несколько и поддерживать логическую инкапсуляцию.

С kotlin это, похоже, не так, если я хочу иметь несколько других классов, которые должны быть видны друг другу, но не в дальнейшем я должен использовать частный модификатор, который ограничивает видимость для одного файла... так что существенно, если у вас было 10 классов в пакете, и только один из них был общедоступным, теперь у вас будет один огромный файл со всеми его классами (и private по всему месту)...

Это обычная практика или есть способ достичь некоторой подобной модульности в котлин?

Я не понимаю, есть ли у них понятие пакета, почему они избавились от доступа, защищенного пакетом...

4b9b3361

Ответ 1

Kotlin по сравнению с Java, похоже, в меньшей степени полагается на модель пакетов (например, структура каталогов не связана с пакетами). Вместо этого Kotlin предлагает internal видимость, которая предназначена для модульной архитектуры проекта. Используя его, вы можете инкапсулировать часть своего кода в отдельный module.

Итак, в объявлениях верхнего уровня вы можете использовать

  • private, чтобы ограничить видимость файла
  • internal, чтобы ограничить видимость модуля

В этот момент нет другого варианта ограничения видимости.

Ответ 2

Как указывает @chkeys, вы можете использовать ключевое слово internal в module. Обычно я работаю с eclipse и maven, и мне не очень удобно создавать эти модули.

Возможно, для другого стека технологий с IDEA или Gradle это более практично; Я не знаю, потому что никогда не использовал их.

Другим вариантом является размещение всех классов пакета внутри одного файла. Это не всегда практично или элегантно.

Для меня видимость package чрезвычайно полезна для ее документального значения. Я хочу знать, какой публичный интерфейс представляет какой-то пакет для остальной части проекта. Я хочу скрыть классы реализации factory и так далее.

Таким образом, даже если вы можете взломать свой путь в Java для классов и методов класса private, мне все равно нравится использовать ключевое слово package.

Я создал проект с одной аннотацией:

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 {

}

Затем я могу использовать эту аннотацию в любом проекте Котлина.

Второй шаг, который у меня еще нет, и я бы хотел сделать в какой-то момент, создает правило PMD для обеспечения соблюдения этого с помощью maven (или любого другого инструмента сборки в этом отношении), а также способный видеть нарушения правила в моей среде IDE с плагином pmd.

В настоящий момент Kotlin еще не является одним из языков, поддерживаемых pmd (т.е. с собственным модулем). Но PMD находится в активном развитии, и Kotlin растет в популярности, поэтому есть шанс, что он будет развиваться в какой-то момент. Это просто мое лучшее предположение.