CODEWITHSUNDEEP
javaaccess-modifiers
user485498
user485498

Reputation:

Java classes and methods Question

As someone learning Java from scratch, who knows a little Python, I have been wondering whats with all the access modifiers (public, static, protected...) in Java. I know what they mean, but why use them?

It's just something that's been bugging me, because whenever I write a new class and I write the instance variables I constantly have to ask myself do I want this variable to be private, public, final etc? I usually come to the conclusion I dont care for the majority of varibles and methods. There are a few instances where I know I will need to call the method from another class, but why not just make all methods public? Is it because in large projects you cant trust another developer isn't going to start rummaging around and messing up your code?

Upvotes: 2

Views: 191

Answers (5)

Bozho
Bozho

Reputation: 597362

Use the minimal visibility modifier in each case. For example fields should be private in almost all cases.

Methods can be:

  • private - if they are used only in the current class, as helpers.
  • protected, if you want them to be accessible to subclasses only, but not to other classes. This is when you design your class for inheritance, and you want to provide hooks for subclasses.
  • package-private - if you want to use these methods inside the same package, but don't want to expose them to the outside world

These all relate to API design - what functionality you want your API to expose and what not. That is - which methods are internal to your implementation, and which should be usable by classes that use your class to do their job.

The advantage of all this is that you can change private/package-private methods without anyone else but your own class/package relying on them. Making them public ties you to supporting them. This is true not only when you are designing an API like the collections framework. It's also true when you design your own API inside your own project. Classes have to be aware of much less methods (and hence are easier to change and support).

See this presentation by Joshua Bloch on API design (specifically from 29:00)

Upvotes: 4

Brad Mace
Brad Mace

Reputation: 27906

It's all about how much of your API is exposed, and therefore how much is going to break when you change it.

  • private code can be changed any time you like and you know you'll only be affecting your own code in that one file.

  • default (package private) you're still affecting only your own code (with possible exception of certain package trickery), but you'll have to check more of it.

  • protected: other peoples' code may be using it, but since it's limited to subclasses they can usually update their code fairly easily.

  • public code may be in extensive use by other peoples' code. Changing this may force other people to modify their code all throughout their own project. If you know other people are using your code you probably shouldn't change these methods until you've released a few versions with them marked as @deprecated so that those people have a change to update their code in advance of it breaking.

Upvotes: 0

thejh
thejh

Reputation: 45578

It is, for example, useful when you have a library that you want to be able to update without changing too much in your code. Public methods normally stay while private ones can change. If the library author would make everything public, library users could accidentially use such implementation-specific methods, making updating the library harder.

Upvotes: 0

santiagobasulto
santiagobasulto

Reputation: 11726

It's an OO concept. First of all, for example, "final" is a modifier that will make that variable a "constant", then if you need a constat you have to use it. When you start coding real life projects you will see the advantage of having this type of encapsulation. Don't understimate it.

A example is when your coding a method that can, for example, change in the future.

public void save(Person p){
    this.saveInTheDataBase(p);
}
private void saveInTheDataBase(Person p){
   database.save(p);
}
private void saveInFile(Person p){
   file.save(p);
}

Then, your clients will call to save(); without taking care where it gets saved

Upvotes: 0

hvgotcodes
hvgotcodes

Reputation: 120308

The access modifiers are so programmers can program in an OO way and use data encapsulation to write airtight (or as close as possible) APIs.

Agreed, its not always desirable. Thats why there are other options.

Upvotes: 0

Related Questions