Mailing-List: contact mahout-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mahout-dev@lucene.apache.org
Message-ID: <1550032018.1257599432408.JavaMail.jira@brutus>
Date: Sat, 7 Nov 2009 13:10:32 +0000 (UTC)
From: "Sean Owen (JIRA)" <jira@apache.org>
To: mahout-dev@lucene.apache.org
Subject: [jira] Updated: (MAHOUT-190) Make all instance fields private
In-Reply-To: <327928161.1256646419351.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/MAHOUT-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Owen updated MAHOUT-190:
-----------------------------

    Attachment: MAHOUT-190_2.patch

OK went ahead and made the rest of the changes I think are appropriate given discussion on the issue. Final part 2 patch attached, looking to submit Monday.

> 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
>
>         Attachments: MAHOUT-190_1.patch, MAHOUT-190_2.patch, MAHOUT-190_2.patch
>
>
> 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.