[
https://issues.apache.org/jira/browse/MAHOUT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770720#action_12770720
]
Jake Mannix commented on MAHOUT-190:
------------------------------------
bq. Surely Sean is merely advocating at the core that we forbid access to
instance variables except via getter and setter.
Yeah, but for the sake of argument, when do we go and create those get/set
methods? We go through now and add them for everything, and by default make
these methods protected? If we don't, we've hidden them completely and they're
not available, but if we do, that's a crazy lot of methods added, most of the
time when they're not necessary, because nobody should be using them (ie. they
are the "clear" cases Sean talks about, of private inner stuff nobody should
use - implementation details and so forth).
So we need to decide which are the "clearly" inner, make those private with no
getters, let alone setters, and then go through the "possibly extendable"
cases, make those private with protected getter (and setter, if it looks like
this is somethign that doesn't need to be final/immutable), and then find the
cases of basically public stuff, and make them private with public access
methods.
I guess what I'm advocating is that this be taken in a case-by-case basis,
instead of a blanket statement of "lets hide everything now, and only add back
accessors later as necessary" - yes, I agree with both of you that the basic
statement of making them private is fine, as long as you default to imagining
the world where an advanced user might think of doing something different with
things, and only don't provide at least protected access via accessors when you
are really really sure that nobody should access these in any possible
subclass. I personally tend to think that subclasses, since they follow the
"is a" qualifier w.r.t. their parent, deserve to be allowed to access a fair
amount of their parent. The problem with this kind of approach, as I keep
saying, is that it leads to a proliferation of protected accessor methods.
This isn't doesn't rule out doing this, but it's a slight strike against it in
my eyes.
> 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.
