Visibility and encapsulation
Visibility and encapsulation
A register should allow readers to see its attendance count while keeping changes behind an intentional method. Access control states where declarations may be used. It helps maintain an API contract rather than relying on every caller to avoid changing internal fields.
What you’ll learn
- Expose reads while restricting writes.
- Choose a module-appropriate visibility boundary.
Visibility and encapsulation in the example
Readable state
A register should allow readers to see its attendance count while keeping changes behind an intentional method.
Readable stateControlled operation
Kotlin public is the default visibility.
Controlled operationRestricted setter
The controlled method increments count to one.
Restricted setter
Understand visibility and encapsulation
Kotlin public is the default visibility. Internal limits access to a module, private restricts an implementation boundary, and protected applies to suitable subclass access. A private setter can expose a property for reading while directing writes through a deliberate method.
Follow visibility and encapsulation
Save the complete source as Main.kt and use the Kotlin/JVM environment. No separate input file is needed.
Kotlin/JVM · complete program
class Register {
var count: Int = 0
private set
fun recordArrival() { count++ }
}
fun main() {
val register = Register()
register.recordArrival()
println(register.count)
}Expected output
1Follow the execution
The controlled method increments count to one. A caller can read it but cannot directly assign a different count through the private setter. This allows update rules to be centralized inside the register.
Try this in the Kotlin compiler by pasting the complete program.
Practice: Visibility and encapsulation
Your task: Where should you enforce a maximum count?
Kotlin/JVM · complete program
class Register {
var count: Int = 0
private set
fun recordArrival() { count++ }
}
fun main() {
val register = Register()
register.recordArrival()
println(register.count)
}Worked answer
In the operation that changes count, with an explicit result when the limit is reached. Restricted writes help keep callers from bypassing that policy.
Visibility and encapsulation: the important boundary
Visibility is an API rule, not encryption or a guarantee against someone controlling the process. Kotlin modules and JVM packages are not the same boundary, so internal should not be described as Java package-private.
Check your understanding
Visibility and encapsulation: what to keep in mind
In the operation that changes count, with an explicit result when the limit is reached. Restricted writes help keep callers from bypassing that policy. Visibility is an API rule, not encryption or a guarantee against someone controlling the process.
Further reading: official Kotlin documentation for this topic.
Reaching the recap and completing the quizzes are separate milestones.