In Java, differenza tra pacchetto privato, pubblico, protetto e privato

In Java, ci sono regole chiare su quando utilizzare ognuno dei modificatori di accesso, vale a dire il predefinito (pacchetto privato), public , protected e private , mentre si fa class e interface e si occupa dell’ereditarietà?

Il tutorial ufficiale potrebbe esserti utile.

             │ Classe │ Pacchetto │ Sottoclass │ Sottoclass │ Mondo
             │ │ │ (stesso pkg) │ (diff pkg) │ 
 ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
 public │ + │ + │ + │ + │ +     
 ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
 protetto │ + │ + │ + │ + │         
 ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
 nessun modificatore │ + │ + │ + │ │    
 ────────────┼───────┼─────────┼──────────┼──────── ──┼────────
 privato │ + │ │ │ │    

 +: accessibile
 vuoto: non accessibile

(Caveat: Io non sono un programmatore Java, sono un programmatore Perl. Perl non ha protezioni formali che è forse il motivo per cui capisco il problema così bene :))

Privato

Come penseresti, solo la class in cui è dichiarata può vederla.

Pacchetto privato

Può essere visto e utilizzato solo dal pacchetto in cui è stato dichiarato. Questo è il default in Java (che alcuni vedono come un errore).

protetta

Il pacchetto Private + può essere visto da sottoclassi o membri del pacchetto.

Pubblico

Tutti possono vederlo.

Pubblicato

Visibile al di fuori del codice che controllo. (Anche se non è la syntax Java, è importante per questa discussione).

Il C ++ definisce un livello aggiuntivo chiamato “amico” e meno ne sai e meglio è.

Quando dovresti usare cosa? L’intera idea è l’incapsulamento per hide le informazioni. Per quanto ansible, si desidera hide i dettagli di come viene fatto qualcosa dai propri utenti. Perché? Perché allora puoi cambiarli più tardi e non infrangere il codice di nessuno. Questo ti consente di ottimizzare, refactoring, riprogettare e correggere bug senza preoccuparti che qualcuno stia usando quel codice che hai appena revisionato.

Quindi, la regola generale è di rendere le cose solo visibili come devono essere. Inizia con privato e aggiungi solo più visibilità se necessario. Rendi pubblico solo ciò che è assolutamente necessario che l’utente sappia, ogni dettaglio che rendi crampi pubblici la tua capacità di ridisegnare il sistema.

Se si desidera che gli utenti siano in grado di personalizzare i comportamenti, piuttosto che rendere pubblici gli interni in modo che possano sovrascriverli, è spesso un’idea migliore spingere quegli intestini in un object e rendere pubblica tale interfaccia. In questo modo possono semplicemente inserire un nuovo object. Ad esempio, se stavi scrivendo un lettore CD e volessi il bit “vai a trovare informazioni su questo CD” personalizzabile, piuttosto che rendere pubblici quei metodi, inseriresti tutte queste funzionalità nel proprio object e renderebbe pubblico solo il tuo object getter / setter . In questo modo essere avidi nell’esporre le tue viscere incoraggia una buona composizione e separazione delle preoccupazioni

Personalmente, rimango solo con “privato” e “pubblico”. Molte lingue OO hanno questo. “Protetto” può essere utile, ma è davvero un trucco. Una volta che un’interfaccia è più che privata, è fuori dal tuo controllo e devi cercare nel codice di altre persone per trovare gli usi.

È qui che entra in gioco l’idea di “pubblicato”. Cambiare un’interfaccia (refactoring) richiede che tu trovi tutto il codice che lo sta usando e lo cambi anche. Se l’interfaccia è privata, nessun problema. Se è protetto devi trovare tutte le sottoclassi. Se è pubblico devi trovare tutto il codice che usa il tuo codice. A volte questo è ansible, ad esempio se stai lavorando su un codice aziendale che è solo per uso interno, non importa se un’interfaccia è pubblica. Puoi estrarre tutto il codice dal repository aziendale. Ma se un’interfaccia è “pubblicata”, se c’è del codice che la utilizza al di fuori del tuo controllo, allora tu verrai disinformato. È necessario supportare tale interfaccia o rischiare di violare il codice. Anche le interfacce protette possono essere considerate pubblicate (motivo per cui non mi preoccupo di proteggere).

Molte lingue trovano la natura gerarchica di pubblico / protetto / privato troppo limitante e non in linea con la realtà. A tal fine c’è il concetto di una class di tratto , ma questo è un altro spettacolo.

Ecco una versione migliore del tavolo. (Prova futura con una colonna per i moduli.)

Modificatori di accesso Java

spiegazioni

  • Un membro privato è accessibile solo all’interno della stessa class dichiarata.

  • Un membro senza modificatore di accesso è accessibile solo all’interno di classi nello stesso pacchetto.

  • Un membro protetto è accessibile all’interno di tutte le classi nello stesso pacchetto e in sottoclassi in altri pacchetti.

  • Un membro pubblico è accessibile a tutte le classi (a meno che non risieda in un modulo che non esporta il pacchetto in cui è dichiarato).


Quale modificatore scegliere?

I modificatori di accesso sono uno strumento che ti aiuta a prevenire l’incapsulamento accidentale (*) . Chiediti se intendi che il membro sia qualcosa che è interno alla class, al pacchetto, alla gerarchia di classi o non sia interno e scegli il livello di accesso di conseguenza.

Esempi:

  • Probabilmente un long internalCounter field del campo dovrebbe essere privato dato che è mutabile e un dettaglio di implementazione.
  • Una class che dovrebbe essere istanziata solo in una class factory (nello stesso pacchetto) dovrebbe avere un costruttore a pacchetto limitato, dal momento che non dovrebbe essere ansible chiamarlo direttamente dall’esterno del pacchetto.
  • Un metodo interno void beforeRender() chiamato right prima del rendering e usato come un hook in sottoclassi dovrebbe essere protetto.
  • Un void saveGame(File dst) che viene chiamato dal codice della GUI dovrebbe essere pubblico.

(*) Che cos’è esattamente l’incapsulamento?

  | highest precedence < ---------> lowest precedence *———————————————+———————————————+———————————+———————————————+——————— \ xCanBeSeenBy | this | any class | this subclass | any \__________ | class | in same | in another | class \ | nonsubbed | package | package | Modifier of x \ | | | | ————————————————*———————————————+———————————+———————————————+——————— public | ✔ | ✔ | ✔ | ✔ ————————————————+———————————————+———————————+———————————————+——————— protected | ✔ | ✔ | ✔ | ✘ ————————————————+———————————————+———————————+———————————————+——————— package-private | | | | (no modifier) | ✔ | ✔ | ✘ | ✘ ————————————————+———————————————+———————————+———————————————+——————— private | ✔ | ✘ | ✘ | ✘ 

Regola facile Inizia con dichiarare tutto privato. E poi progredire verso il pubblico man mano che sorgono i bisogni e il design lo garantisce.

Quando esponi i membri chiedi a te stesso se stai esponendo le scelte di rappresentazione o le scelte di astrazione. Il primo è qualcosa che si vuole evitare in quanto introdurrà troppe dipendenze dalla rappresentazione reale piuttosto che dal suo comportamento osservabile.

Come regola generale, cerco di evitare di sovrascrivere le implementazioni del metodo tramite la sottoclass; è troppo facile rovinare la logica. Dichiarare metodi protetti astratti se si intende farlo sovrascrivere.

Inoltre, utilizzare l’annotazione @ Override quando si esegue l’override per evitare che le cose si rompano quando si effettua il refactoring.

In realtà è un po ‘più complicato di una semplice griglia. La griglia ti dice se è permesso un accesso, ma cosa costituisce esattamente un accesso? Inoltre, i livelli di accesso interagiscono con le classi e l’ereditarietà nidificate in modi complessi.

L’accesso “predefinito” (specificato dall’assenza di una parola chiave) viene anche chiamato pacchetto-privato . Eccezione: in un’interfaccia, nessun modificatore significa accesso pubblico; i modificatori diversi dal pubblico sono vietati. Le costanti Enum sono sempre pubbliche.

Sommario

È consentito l’accesso a un membro con questo identificatore di accesso?

  • Il membro è private : solo se il membro è definito all’interno della stessa class del codice chiamante.
  • Il membro è privato del pacchetto: solo se il codice chiamante si trova nel pacchetto che include immediatamente il membro.
  • Il membro è protected : lo stesso pacchetto o se il membro è definito in una superclass della class che contiene il codice chiamante.
  • Il membro è public : sì.

A chi si applicano gli specificatori di accesso

Le variabili locali e i parametri formali non possono prendere gli identificatori di accesso. Dal momento che sono intrinsecamente inaccessibili all’esterno secondo le regole dell’ambito, sono effettivamente privati.

Per le classi nell’ambito top, sono consentiti solo public e package-private. Questa scelta progettuale è presumibilmente perché protected e private sarebbero ridondanti a livello di pacchetto (non vi è alcuna ereditarietà dei pacchetti).

Tutti gli specificatori di accesso sono possibili sui membri della class (costruttori, metodi e funzioni dei membri statici, classi nidificate).

Correlato: Accessibilità della class Java

Ordine

Gli specificatori di accesso possono essere ordinati rigorosamente

pubblico> protetto> pacchetto-privato> privato

il che significa che il public fornisce il massimo accesso, il minimo private . Qualsiasi riferimento ansible su un membro privato è valido anche per un membro privato del pacchetto; qualsiasi riferimento a un membro privato del pacchetto è valido su un membro protetto e così via. (Dare l’accesso ai membri protetti ad altre classi nello stesso pacchetto è stato considerato un errore).

Gli appunti

  • I metodi di una class sono autorizzati ad accedere a membri privati ​​di altri oggetti della stessa class. Più precisamente, un metodo di class C può accedere a membri privati ​​di C su oggetti di qualsiasi sottoclass di C. Java non supporta la limitazione dell’accesso per istanza, solo per class. (Confrontati con Scala, che lo supporta utilizzando private[this] .)
  • È necessario accedere a un costruttore per build un object. Pertanto, se tutti i costruttori sono privati, la class può essere costruita solo dal codice che vive all’interno della class (in genere metodi di factory statici o inizializzatori di variabili statiche). Allo stesso modo per i costruttori di pacchetti privati ​​o protetti.
    • Solo avere costruttori privati ​​significa anche che la class non può essere sottoclassata esternamente, dal momento che Java richiede ai costruttori di una sottoclass di chiamare implicitamente o esplicitamente un costruttore di superclass. (Può tuttavia contenere una class nidificata che la sottoclass).

Classi interne

Devi anche considerare gli ambiti annidati , come le classi interne. Un esempio della complessità è che le classi interne hanno membri, che a loro volta possono prendere modificatori di accesso. Quindi puoi avere una class privata interna con un membro pubblico; si può accedere al membro? (Vedi sotto). La regola generale è guardare lo scope e pensare in modo ricorsivo per vedere se è ansible accedere ad ogni livello.

Tuttavia, questo è abbastanza complicato, e per i dettagli completi, consultare la specifica del linguaggio Java . (Sì, ci sono stati errori nel compilatore in passato.)

Per un assaggio di come questi interagiscono, considera questo esempio. È ansible “perdere” classi interne private; questo di solito è un avvertimento:

 class Test { public static void main(final String ... args) { System.out.println(Example.leakPrivateClass()); // OK Example.leakPrivateClass().secretMethod(); // error } } class Example { private static class NestedClass { public void secretMethod() { System.out.println("Hello"); } } public static NestedClass leakPrivateClass() { return new NestedClass(); } } 

Uscita del compilatore:

 Test.java:4: secretMethod() in Example.NestedClass is defined in an inaccessible class or interface Example.leakPrivateClass().secretMethod(); // error ^ 1 error 

Alcune domande correlate:

  • Java – Accessibilità del metodo all’interno della class pacchetto-privata?

Come regola generale:

  • privato : ambito di class.
  • default (o package-private ): scope del pacchetto.
  • protected : package scope + child (come pacchetto, ma possiamo suddividerlo in sottoclassi da pacchetti diversi). Il modificatore protetto mantiene sempre la relazione “genitore-figlio”.
  • pubblico : ovunque.

Di conseguenza, se dividiamo il diritto di accesso in tre diritti:

  • (D) irect (richiama da un metodo all’interno della stessa class).
  • (R) eference (invoca un metodo usando un riferimento alla class, o tramite syntax “punto”).
  • (I) nheritance (tramite sottoclass).

allora abbiamo questa semplice tabella:

 +—-———————————————+————————————+———————————+ | | Same | Different | | | Package | Packages | +—————————————————+————————————+———————————+ | private | D | | +—————————————————+————————————+———————————+ | package-private | | | | (no modifier) | DRI | | +—————————————————+————————————+———————————+ | protected | DRI | I | +—————————————————+————————————+———————————+ | public | DRI | RI | +—————————————————+————————————+———————————+ 

In brevissimo

  • public : accessibile da ogni luogo.
  • protected : accessibile dalle classi dello stesso pacchetto e delle sottoclassi che risiedono in qualsiasi pacchetto.
  • default (nessun modificatore specificato): accessibile dalle classi dello stesso pacchetto.
  • private : accessibile solo nella stessa class.

Il modificatore di accesso più incompreso in Java è protected . Sappiamo che è simile al modificatore predefinito con un’eccezione in cui le sottoclassi possono vederlo. Ma come? Ecco un esempio che si spera chiarisca la confusione:

  • Supponiamo di avere 2 classi; Father e Son , ciascuno nel proprio pacchetto:

     package fatherpackage; public class Father { } ------------------------------------------- package sonpackage; public class Son extends Father { } 
  • Aggiungiamo un metodo protetto foo() a Father .

     package fatherpackage; public class Father { protected void foo(){} } 
  • Il metodo foo() può essere chiamato in 4 contesti:

    1. All’interno di una class che si trova nello stesso pacchetto in cui è definito foo() ( fatherpackage ):

       package fatherpackage; public class SomeClass { public void someMethod(Father f, Son s) { f.foo(); s.foo(); } } 
    2. All’interno di una sottoclass, nell’istanza corrente tramite this o super :

       package sonpackage; public class Son extends Father { public void sonMethod() { this.foo(); super.foo(); } } 
    3. Su un riferimento il cui tipo è della stessa class:

       package fatherpackage; public class Father { public void fatherMethod(Father f) { f.foo(); // valid even if foo() is private } } ------------------------------------------- package sonpackage; public class Son extends Father { public void sonMethod(Son s) { s.foo(); } } 
    4. Su un riferimento il cui tipo è la class genitore e si trova all’interno del pacchetto in cui è definito foo() ( fatherpackage ) [Questo può essere incluso nel contesto n. 1]:

       package fatherpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); } } 
  • Le seguenti situazioni non sono valide.

    1. Su un riferimento il cui tipo è la class genitore e si trova all’esterno del pacchetto in cui è definito foo() ( fatherpackage ):

       package sonpackage; public class Son extends Father { public void sonMethod(Father f) { f.foo(); // compilation error } } 
    2. Una non sottoclass all’interno di un pacchetto di una sottoclass (una sottoclass eredita i membri protetti dal suo genitore e li rende privati ​​di non sottoclassi):

       package sonpackage; public class SomeClass { public void someMethod(Son s) throws Exception { s.foo(); // compilation error } } 

Privato

  • Metodi, Variabili e Costruttori

Metodi, variabili e costruttori dichiarati privati ​​sono accessibili solo all’interno della class dichiarata.

  • Classe e interfaccia

Il modificatore di accesso privato è il livello di accesso più restrittivo. La class e le interfacce non possono essere private.

Nota

Le variabili dichiarate private sono accessibili al di fuori della class se nella class sono presenti metodi getter pubblici. Variabili, metodi e costruttori che sono dichiarati protetti in una superclass sono accessibili solo dalle sottoclassi di un altro pacchetto o di qualsiasi class all’interno del pacchetto della class dei membri protetti.


protetta

  • Classe e interfaccia

Il modificatore di accesso protetto non può essere applicato alla class e alle interfacce.

Metodi, i campi possono essere dichiarati protetti, tuttavia i metodi e i campi in un’interfaccia non possono essere dichiarati protetti.

Nota

L’accesso protetto consente alla sottoclass di utilizzare il metodo o la variabile helper, impedendo al contempo a una class non correlata di tentare di utilizzarla.


Pubblico

Una class, un metodo, un costruttore, un’interfaccia, ecc., Dichiarato pubblico, è accessibile da qualsiasi altra class.

Pertanto è ansible accedere a campi, metodi, blocchi dichiarati all’interno di una class pubblica da qualsiasi class appartenente all’universo Java.

  • Pacchetti diversi

Tuttavia, se la class pubblica a cui stiamo tentando di accedere si trova in un pacchetto diverso, la class pubblica deve ancora essere importata.

A causa dell’ereditarietà delle classi, tutti i metodi pubblici e le variabili di una class sono ereditati dalle sue sottoclassi.


Predefinito -Nessuna parola chiave:

Il modificatore di accesso predefinito significa che non dichiariamo esplicitamente un modificatore di accesso per una class, un campo, un metodo, ecc.

  • All’interno degli stessi pacchetti

Una variabile o un metodo dichiarato senza alcun modificatore del controllo di accesso è disponibile per qualsiasi altra class nello stesso pacchetto. I campi di un’interfaccia sono implicitamente statici finali pubblici e i metodi in un’interfaccia sono di pubblico dominio.

Nota

Non possiamo sovrascrivere i campi Statici. Se provi a sovrascriverli, non mostra alcun errore, ma non funziona a parte noi.

Risposte correlate

  • Sovrascrittura dei metodi statici in java

Link di riferimenti

http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html http://www.tutorialspoint.com/java/java_access_modifiers.htm

La differenza può essere trovata nei collegamenti già forniti, ma quale da usare di solito si riferisce al “Principio di minima conoscenza”. Consenti solo la minima visibilità necessaria.

Privato : accesso limitato alla sola class

Predefinito (nessun modificatore) : accesso limitato alla class e al pacchetto

Protetto : accesso limitato a classi, pacchetti e sottoclassi (pacchetto interno ed esterno)

Pubblico : accessibile per class, pacchetto (tutti) e sottoclassi … In breve, ovunque.

Modificatori di accesso in Java.

I modificatori di accesso Java vengono utilizzati per fornire il controllo degli accessi in Java.

1. Predefinito:

Accessibile solo alle classi nello stesso pacchetto.

Per esempio,

 // Saved in file A.java package pack; class A{ void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B{ public static void main(String args[]){ A obj = new A(); // Compile Time Error obj.msg(); // Compile Time Error } } 

Questo accesso è più limitato di pubblico e protetto, ma meno limitato del privato.

2. Pubblico

Si può accedere da qualsiasi luogo. (Accesso globale)

Per esempio,

 // Saved in file A.java package pack; public class A{ public void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B{ public static void main(String args[]){ A obj = new A(); obj.msg(); } } 

Uscita: Ciao

3. Privato

Accessibile solo all’interno della stessa class.

Se si tenta di accedere a membri privati ​​su una class in un’altra verrà generato un errore di compilazione. Per esempio,

 class A{ private int data = 40; private void msg(){System.out.println("Hello java");} } public class Simple{ public static void main(String args[]){ A obj = new A(); System.out.println(obj.data); // Compile Time Error obj.msg(); // Compile Time Error } } 

4. Protetto

Accessibile solo alle classi nello stesso pacchetto e alle sottoclassi

Per esempio,

 // Saved in file A.java package pack; public class A{ protected void msg(){System.out.println("Hello");} } // Saved in file B.java package mypack; import pack.*; class B extends A{ public static void main(String args[]){ B obj = new B(); obj.msg(); } } 

Uscita: Ciao

Inserisci qui la descrizione dell'immagine

I modificatori di accesso sono lì per limitare l’accesso a diversi livelli.

Pubblico: è fondamentalmente tanto semplice quanto è ansible accedere da qualsiasi class, indipendentemente dal fatto che si trovi nello stesso pacchetto o meno.

Per accedere se si è nello stesso pacchetto è ansible accedere direttamente, ma se si è in un altro pacchetto, è ansible creare un object della class.

Predefinito: è accessibile nello stesso pacchetto da qualsiasi class di pacchetto.

Per accedere puoi creare un object della class. Ma non puoi accedere a questa variabile al di fuori del pacchetto.

Protetto: puoi accedere alle variabili nello stesso pacchetto e sottoclass in qualsiasi altro pacchetto. quindi in pratica è predefinito + comportamento ereditato .

Per accedere al campo protetto definito nella class base è ansible creare l’object della class figlio.

Privato: può essere accesso nella stessa class.

Nei metodi non statici è ansible accedere direttamente a causa di questo riferimento (anche nei costruttori) ma per accedere ai metodi statici è necessario creare l’object della class.

Visibile al pacchetto. Il predefinito. Non sono necessari modificatori.

Visibile solo alla class ( privata ).

Visibile al mondo ( pubblico ).

Visibile al pacchetto e a tutte le sottoclassi ( protette ).

Variabili e metodi possono essere dichiarati senza alcun modificatore chiamato. Esempi predefiniti:

 String name = "john"; public int age(){ return age; } 

Modificatore di accesso privato – privato:

Metodi, variabili e costruttori dichiarati privati ​​sono accessibili solo all’interno della class dichiarata. Il modificatore di accesso privato è il livello di accesso più restrittivo. La class e le interfacce non possono essere private.

Le variabili dichiarate private sono accessibili al di fuori della class se nella class sono presenti metodi getter pubblici.

L’utilizzo del modificatore privato è il modo principale in cui un object si incapsula e nasconde i dati dal mondo esterno.

Esempi:

 Public class Details{ private String name; public void setName(String n){ this.name = n; } public String getName(){ return this.name; } } 

Modificatore di accesso pubblico – pubblico:

Una class, metodo, costruttore, interfaccia, ecc. Dichiarato pubblico può essere accessibile da qualsiasi altra class. Pertanto è ansible accedere a campi, metodi, blocchi dichiarati all’interno di una class pubblica da qualsiasi class appartenente all’universo Java.

Tuttavia, se la class pubblica a cui stiamo tentando di accedere si trova in un pacchetto diverso, la class pubblica deve ancora essere importata.

Because of class inheritance, all public methods and variables of a class are inherited by its subclasss.

Esempio:

 public void cal(){ } 

Protected access modifier – protected:

Variables, methods and constructors which are declared protected in a superclass can be accessed only by the subclasss in another package or any class within the package of the protected members’ class.

The protected access modifier cannot be applied to class and interfaces. Methods, fields can be declared protected, however methods and fields in a interface cannot be declared protected.

Protected access gives the subclass a chance to use the helper method or variable, while preventing a nonrelated class from trying to use it.

 class Van{ protected boolean speed(){ } } class Car{ boolean speed(){ } } 

I just want to address a detail that is extremely commonly got wrong, including by most of the answers on this page. “Default” access (when no access modifier is present) is not always the same as package-private . It depends on what the thing is.

  • Non-member types (that is, classs, enums, interfaces, and annotation types not declared inside another type) are package-private by default. ( JLS §6.6.1 )

  • Class members and constructors are package-private by default. ( JLS §6.6.1 )

  • Enum constructors are private by default . (Indeed, enum contructors must be private, and it is an error to try to make them public or protected). Enum constants are public, and do not allow any access specifier. Other members of enums are package-private by default. ( JLS §8.9 )

  • All members of interfaces and annotation types are public by default . (Indeed, members of interfaces and annotation types must be public, and it is an error to try to make them private or protected.) ( JLS §9.3 to 9.5 )

This page writes well about the protected & default access modifier

…. Protected: Protected access modifier is the a little tricky and you can say is a superset of the default access modifier. Protected members are same as the default members as far as the access in the same package is concerned. The difference is that, the protected members are also accessible to the subclasss of the class in which the member is declared which are outside the package in which the parent class is present.

But these protected members are “accessible outside the package only through inheritance“. ie you can access a protected member of a class in its subclass present in some other package directly as if the member is present in the subclass itself. But that protected member will not be accessible in the subclass outside the package by using parent class’s reference. ….

  • public – accessible from anywhere in the application.

  • default – accessible from package.

  • protected – accessible from package and sub-classs in other package. as well

  • private – accessible from its class only.

David’s answer provides the meaning of each access modifier. As for when to use each, I’d suggest making public all classs and the methods of each class that are meant for external use (its API), and everything else private.

Over time you’ll develop a sense for when to make some classs package-private and when to declare certain methods protected for use in subclasss.

  • Visible to the package. the default . No modifiers are needed.
  • Visible to the class only; private .
  • Visible to the world; public .
  • Visible to the package and all subclasss; protected .

So let’s talk about Access Control and Inheritance The following rules for inherited methods are,

  • Methods declared public in a superclass also must be public in all subclasss.
  • Methods declared protected in a superclass must either be protected or public in subclasss; they cannot be private.
  • Methods declared without access control (no modifier was used) can be declared more private in subclasss.
  • Methods declared private are not inherited at all, so there is no rule for them.

Note: This is just a supplement for the accepted answer.

This is related to Java Access Modifiers .

From Java Access Modifiers :

A Java access modifier specifies which classs can access a given class and its fields, constructors and methods. Access modifiers can be specified separately for a class, its constructors, fields and methods. Java access modifiers are also sometimes referred to in daily speech as Java access specifiers, but the correct name is Java access modifiers. Classes, fields, constructors and methods can have one of four different Java access modifiers:

  • Elemento dell’elenco
  • private
  • default (package)
  • protected
  • public

From Controlling Access to Members of a Class tutorials:

Access level modifiers determine whether other classs can use a particular field or invoke a particular method. There are two levels of access control:

  • At the top level—public, or package-private (no explicit modifier).
  • At the member level—public, private, protected, or package-private (no explicit modifier).

A class may be declared with the modifier public, in which case that class is visible to all classs everywhere. If a class has no modifier (the default, also known as package-private), it is visible only within its own package

The following table shows the access to members permitted by each modifier.

 ╔═════════════╦═══════╦═════════╦══════════╦═══════╗ ║ Modifier ║ Class ║ Package ║ Subclass ║ World ║ ╠═════════════╬═══════╬═════════╬══════════╬═══════╣ ║ public ║ Y ║ Y ║ Y ║ Y ║ ║ protected ║ Y ║ Y ║ Y ║ N ║ ║ no modifier ║ Y ║ Y ║ N ║ N ║ ║ private ║ Y ║ N ║ N ║ N ║ ╚═════════════╩═══════╩═════════╩══════════╩═══════╝ 

The first data column indicates whether the class itself has access to the member defined by the access level. As you can see, a class always has access to its own members. The second column indicates whether classs in the same package as the class (regardless of their parentage) have access to the member. The third column indicates whether subclasss of the class declared outside this package have access to the member. The fourth column indicates whether all classs have access to the member.

Access levels affect you in two ways. First, when you use classs that come from another source, such as the classs in the Java platform, access levels determine which members of those classs your own classs can use. Second, when you write a class, you need to decide what access level every member variable and every method in your class should have.

Public Protected Default and private are access modifiers.

They are meant for encapsulation, or hiding and showing contents of the class.

  1. Class can be public or default
  2. Class members can be public, protected, default or private.

Private is not accessible outside the class Default is accessible only in the package. Protected in package as well as any class which extends it. Public is open for all.

Normally, member variables are defined private, but member methods are public.

Often times I’ve realized that remembering the basic concepts of any language can made possible by creating real-world analogies. Here is my analogy for understanding access modifiers in Java:

Let’s assume that you’re a student at a university and you have a friend who’s coming to visit you over the weekend. Suppose there exists a big statue of the university’s founder in the middle of the campus.

  • When you bring him to the campus, the first thing that you and your friend sees is this statue. This means that anyone who walks in the campus can look at the statue without the university’s permission. This makes the statue as PUBLIC .

  • Next, you want to take your friend to your dorm, but for that you need to register him as a visitor. This means that he gets an access pass (which is the same as yours) to get into various buildings on campus. This would make his access card as PROTECTED .

  • Your friend wants to login to the campus WiFi but doesn’t have the any credentials to do so. The only way he can get online is if you share your login with him. (Remember, every student who goes to the university also possesses these login credentials). This would make your login credentials as NO MODIFIER .

  • Finally, your friend wants to read your progress report for the semester which is posted on the website. However, every student has their own personal login to access this section of the campus website. This would make these credentials as PRIVATE .

Spero che questo ti aiuti!

When you are thinking of access modifiers just think of it in this way (applies to both variables and methods ):

public –> accessible from every where
private –> accessible only within the same class where it is declared

Now the confusion arises when it comes to default and protected

default –> No access modifier keyword is present. This means it is available strictly within the package of the class. Nowhere outside that package it can be accessed.

protected –> Slightly less stricter than default and apart from the same package classs it can be accessed by sub classs outside the package it is declared.

It is all about encapsulation (or as Joe Phillips stated, least knowledge ).

Start with the most restrictive (private) and see if you need less restrictive modifiers later on.

We all use method and member modifiers like private, public, … but one thing too few developers do is use packages to organize code logically.

For example: You may put sensitive security methods in a ‘security’ package. Then put a public class which accesses some of the security related code in this package but keep other security classs package private . Thus other developers will only be able to use the publicly available class from outside of this package (unless they change the modifier). This is not a security feature, but will guide usage.

 Outside world -> Package (SecurityEntryClass ---> Package private classs) 

Another thing is that classs which depend a lot on each other may end up in the same package and could eventually be refactored or merged if the dependency is too strong.

If on the contrary you set everything as public it will not be clear what should or should not be accessed, which may lead to writing a lot of javadoc (which does not enforce anything via the compiler…).