Jak zaznaczono przez @hotkeys, można użyć słowa kluczowego internal w numerze module. Zazwyczaj pracuję z zaćmieniem i mavenem, a tworzenie modułów nie jest dla mnie praktyczne.
Może dla innego stosu technologii z IDEA lub Gradle jest bardziej praktyczny; Nie wiem, ponieważ nigdy ich nie użyłem.
Inną opcją jest umieszczenie wszystkich klas paczki w jednym pliku. To nie zawsze jest praktyczne lub eleganckie.
Widoczność package jest dla mnie niezwykle pomocna dla jej wartości dokumentowania. Chcę wiedzieć, jaki publiczny interfejs jakiś pakiet prezentuje reszcie projektu. Chcę ukryć klasy implementacji fabrycznych i tak dalej.
Więc nawet jeśli jest możliwe zhackowanie się w Javie na prywatne klasy i pakiety, nadal lubię używać słowa kluczowego package.
Co robiłem jest utworzyć projekt z pojedynczym adnotacji:
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 {
}
Wtedy mogę używać tej adnotacji w każdym projekcie Kotlin.
Drugim krokiem, którego jeszcze nie mam, i chciałbym to zrobić w pewnym momencie, jest stworzenie reguły PMD, aby wymusić to za pomocą maven (lub dowolnego innego narzędzia do budowania), a także być w stanie zobaczyć naruszenie zasady w moim IDE z wtyczką pmd.
W tej chwili Kotlin nie jest jeszcze jednym z języków obsługiwanych przez pmd (tj. Z własnym modułem). Ale PMD aktywnie się rozwija, a Kotlin zyskuje na popularności, więc jest szansa, że zostanie on rozwinięty w pewnym momencie. To tylko moje najlepsze przypuszczenie.
Cóż, podoba mi się wewnętrzny, ale będziemy mieć to naprawione znacznie lepiej w java9, ale nigdy nie widziałem, aby ktoś stworzył ten sam pakiet tylko po to, by użyć kodu ... w końcu, jeśli ktoś jest tak zdeterminowany, aby naruszać modułowość on po prostu skopiuje wkleić kod, jeśli to konieczne ... Chodzi mi o użyteczność. Po prostu umieszczenie ton kodu w jednym pliku jest głupie ... – vach
@vach faktycznie widziałem - i zrobiłem - że. Niektóre biblioteki są frustrująco nieświadome twoich przypadków użycia (nie oznacza to, że jest to dobra praktyka). – Lovis
Ok, ale teraz migruję projekt java do kotlin i mam bardzo dobrą widoczność wymuszoną, typowo są to niektóre narzędzia, które składają się z 4-5 klas, z których tylko jedna jest widoczna dla świata zewnętrznego ... Teraz z kotlinami nie mam żadnej opcji, aby mieć tę samą widoczność, chyba że umieściłbym wszystko w tym samym pliku ... Czy rozumiem to poprawnie lub jest jakiś inny podejście nie wiem? – vach