[
https://issues.apache.org/jira/browse/MAHOUT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770712#action_12770712
]
Ted Dunning commented on MAHOUT-190:
------------------------------------
bq. I know you can make the getter protected, if necessary. But in a library
such as this one, in which every extension is of the "expert" level, assuming
the end user isn't going to need to access "private" data in their operation is
a bad one.
Surely Sean is merely advocating at the core that we forbid access to instance
variables except via getter and setter.
I agree that too much final annotation is (a) pointless and (b) an unnecessary
PITA. On the other hand, final can make code more comprehensible if used
judiciously.
> Make all instance fields private
> --------------------------------
>
> Key: MAHOUT-190
> URL: https://issues.apache.org/jira/browse/MAHOUT-190
> Project: Mahout
> Issue Type: Improvement
> Affects Versions: 0.2
> Reporter: Sean Owen
> Assignee: Sean Owen
> Priority: Minor
> Fix For: 0.3
>
>
> This one may be more controversial but is useful and interesting enough to
> discuss.
> I personally believe instance fields should always be private. I think the
> pro- and con- debate goes like this:
> Making all fields private increases encapsulation. Fields must be made
> explicitly accessible via getters and setters, which is good -- default to
> hiding, rather than exposing. Not-hiding a field amounts to committing it to
> be a part of the API, which is rarely intended. Using getters/setters allows
> read/write access to be independently controlled and even allowed -- allows
> for read-only 'fields'. Getters/setters establish an API independent from the
> representation which is a Good Thing.
> But don't getters and setters slow things down?
> Trivially. JIT compilers will easily inline one-liners. Making fields private
> more readily allows fields to be marked final, and these two factors allow
> for optimizations by (Proguard or) JIT. It could actually speed things up.
> But isn't it messy to write all those dang getters/setters?
> Not really, and not at all if you use an IDE, which I think we all should be.
> But sometimes a class needs to share representation with its subclasses.
> Yes, and it remains possible with package-private / protected getters and
> setters. This is IMHO a rare situation anyway, and, the code is far easier to
> read when fields from a parent don't magically appear, or one doesn't wonder
> about where else a field may be accessed in subclasses. I also feel like
> sometimes making a field more visible is a shortcut enabler to some bad
> design. It usually is a bad smell.
> Thoughts on this narrative. Once again I volunteer to implement the consensus.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
