Let's start with checking if we deal with Kotlin class and whether this class is internal. We can create a rule that finds all internal Kotlin classes in our application and check if they're accessing other packages. More specifically, a module is a set of Kotlin files compiled. ArchUnit checks the architecture of code during unit tests and can be easily extended using custom rules. So, the internal visibility modifier means that the member is visible within the same module. It turns out we can use the ArchUnit library to achieve that goal. So maybe we can make an internal modifier more strict? For those that do not know, internal modifier restricts the visibility of an element to a particular module: internal class Foo. Using an internal modifier and creating a separate module is cumbersome compared to using package scope back in Java. This makes an internal modifier much broader than its Java counterpart.
On the other hand, Kotlin's internal modifier makes class visible within the same source set of files compiled together.
In Java, class marked with package-private access level is visible only within the same package. However, it has some weak spots Īnother of its pain points is that Kotlin lacks real package-private scope and internal visibility modifier in Kotlin is weaker than the package-private access level in Java. Kotlin is an awesome language that enables developers to write more concise and safer code. Like in Java, Kotlin has multiple visibility modifiers that control how widely a piece of code can be accessed: public internal protected private.
0 kommentar(er)
