If you follow that track, though, you kind of have to start down the path of maybe different things should have different defaults. Unless the class is inherited from something public, that should be enough to keep other code from getting access. On the same note, you could rebuke that by saying that, really, only those classes would need to be internal while keeping their attributes public. You can read about this argument in more detail here. There’s a decent argument against this, largely stating that most of those public artifacts should be something more akin to Kotlin’s internal modifier, but had to be public because Java’s visibility options aren’t the “right” set of options. I can see their point, but I don’t think it’s as likely to be to an issue as they seem to think.įirst off, in JetBrains’ research of Java codebases, there is between 2.5 and 5 times more uses of public than private, and I agree with Kotlin’s decision that defaulting to public makes it all that much cleaner. Those who are against it bring up the principle of hiding everything that you can get away with in order to preserve encapsulation, and that if it’s too easy, people will make things public that shouldn’t be.
public by default (when no visibility modifier is used), and I would just like to pitch in on why I think JetBrains made the right decision on this one. In this article, you have learned about the Kotlin visibility modifiers along with few examples.Some people have spoken against Kotlin’s decision to make classes, methods, etc.
can be private, protected, internal and public. But local declarations (local variables, functions, and classes) can’t have visibility modifiers.
Access modifiers kotlinĪs the name suggests, the visibility modifier controls the visibility or accessibility of declarations (classes, objects, interfaces, constructors, functions, properties, and their setters). In this article, we will go through all the visibility modifiers supported by Kotlin 2.
0 kommentar(er)
