Anu
Anu

Reputation: 1367

Whether to use private modifier for all fields in a standalone swing applicaton?

I have a standalone Swing application with a main class which I will call MainClass. The only access to this MainClass is from the main(String args[]) method of this class. In other words, this class is not going to be used by any other class.

Should I make the member fields of MainClass "private"? I argue that it is redundant since no other class is going to instantiate MainClass, but another more experienced programmer argues that it violated Java best practices to not label a field "private".

Upvotes: 0

Views: 167

Answers (3)

Mik378
Mik378

Reputation: 22191

Java is object-oriented.

Making a private field does not always make sense if setters and getters contains poor no logics.

Indeed, a lot of developers think that creating getters and setters and write private fields IS encapsulation => Wrong!

Why is it important to encapsulate data and especially how ? How object-oriented programming differs from procedural programming?

You could read this article to get some answers: http://pragprog.com/articles/tell-dont-ask
and then this: http://en.wikipedia.org/wiki/Law_of_Demeter
and a little concrete example with this: http://www.devdaily.com/java/java-law-of-demeter-java-examples

So, according to me, about 99% of cases, fields must be private/or package or protected (but never public unless a framework imposes it...rare) and only manipulated by wrapping class methods. And in most cases, it's amazing to notice that 95% of getters/setters can be removed since useless.

It's a totally different way of thinking and difficult to stop thinking procedural, but it gets your code terribly more flexible, clean and nearest to the real world ;)

You said:

I argue that it is redundant since no other class is going to instantiate MainClass

The key for a good design, I think, is to be the most restrictive as long as it allows the creation of the features. If developer is too permissive, program could lead to serious strange conflicts and thus behaviours.

Developer must try to anticipate what would be the program in the future years (for large ones) and be aware that a future developer could make some errors like in your context: instantiate your class outside the main method.

Upvotes: 2

trashgod
trashgod

Reputation: 205875

As discussed in Controlling Access to Members of a Class, no modifier signifies package-private access, which allows visibility to other classes within the same package. If you don't want that, make the member private explicitly.

Upvotes: 1

Rohit Jain
Rohit Jain

Reputation: 213351

In general you should have member fields of a class private only regardless of whether you are using it from inside your class or outside.. (In some cases protected if you want them to be accessible from your base class)

You don't want the outside world to have direct access to your fields... Else you will break the whole concept of Encapsulation.

So having said that, in your particular case also, you should have them as private field..

And even though for now that class will not be accessed from outside, it will be better to be on the safe side..

Upvotes: 2

Related Questions