I came across this discussion on the lack of really private methods in Python. Time and again, some of us feel violated that a method that is supposed to be private is somehow accessible to callers (via permissive reflection or otherwise). However, this reaction misses the point of encapsulation.
Encapsulating an object is not about protecting (or securing) the said object. If you must think in terms of protection, then it is about protecting the consumers (callers) of the object. Encapsulation is about freeing your consumers from the knowledge of your implementation details. By doing so, you insulate your consumers from any ripple effect of changes to your implementation.
The term 'access qualifier' for describing public, protected, private doesn't help. Something like 'visibility indicator' might help avoid the notion of access protection.
2 comments:
Great point! I hope people will be taught OO in this light!
@Karthik
Thanks. Glad you think so. I missed out being fully clear about what I meant so I'll use this opportunity.
If you agree that encapsulation is not about protecting the said object, then it becomes acceptable that consumers(callers) may jump through hoops to get to private methods at their own risk. Risk being not insulated from changes to implementation.
Post a Comment
Note: Only a member of this blog may post a comment.