[
https://issues.apache.org/jira/browse/MAHOUT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770592#action_12770592
]
Jake Mannix commented on MAHOUT-190:
------------------------------------
<em>Replacing it with a getter does little, yes, but it's a step in the right
direction? </em>
I'm a big fan of getters over *public* instance variables, *always*. Over
protected instance variables? It's not so bad, much of the time that seems
fine, yes, esp. when you're exposing it "on purpose" as you say. It's the
exposing it for the advanced user, who is going to subclass, that I'm wondering
about. Like you say, you're not going to go and add protected getters for
everything - only things you think people will need. But then that comes back
to the problem of reading the user's mind...
<em>I'd also advance the opposite problem...</em>
Yeah, this is the only argument I really agree with on this, and the only way
to get around it is to yes, accept that anything that someone can get access
to, via a protected method in a subclass, is in some sense part of the API.
And for the same reasons why you shouldn't have a millions methods on
interfaces (well, some of the same reasons), making an API huge by having
*everything* not public be protected by default is a bad idea.
But early on in a project, when it's evolving fast, and you don't know how
people are going to use it? That's not the time to err on the side of "closed
for modification", it's the time to assume that every user is moderately
advanced (why else would they be using a 0.x product?), and let them try things
out, and maybe you find things that really should be designed for extension
that you didn't realize before. Making it harder for people to monkey-with
just hampers adoption. If users do crazy shit in the internals of a core class
which they're give protected access to, and then in 0.4 we remove those
variables, breaking some implementers, well, they knew what they were getting
into by monkeying with internals in a fast moving project, and they'll probably
bring it up on the lists, we'll all have a big discussion about whether we need
to revert or migrate to getters, and we've all learned something.
When the project is farther along (like Lucene), it's more acceptable to lock
things down, but doing it too early just leads to pain for people who want to
experiment, in my experience.
Does it *hurt* us to not make this kind of design choice, of enforcing this
strict rule, until later on when apis have stabilized and we know who our users
are and what they are doing?
> 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.
