Questa domanda viene sollevata con un chiarimento richiesto per decidere quando dichiarare un metodo protected o public durante la progettazione della classe di un pacchetto.
Il mio punto è, se è necessario sovrascrivere un metodo di SuperClass , quindi rendere il livello di accesso al metodo come package private o protected in SuperClass ma non dare il livello di accesso public e quindi SubClass inherit SuperClass per sovrascrivere quel metodo.
se public metodo di livello di accesso è sovrascritto in SubClass allora public metodo di livello di accesso è anche diventato un metodo dipendente dall'implementazione in ogni nuovo SubClass progettato, che rompe il concetto di abstraction . Poiché l'utente che utilizza public metodo di accesso al livello addNotify() , dovrebbe sapere che l'implementazione è diversa in awt.Component / awt.Checkbox / awt.Button class, il che significa che non è possibile nascondere i dettagli di implementazione qui. Inoltre, abstract class dovrebbe essere scoperto e progettato per avere solo implementazioni comuni dei suoi metodi concrete subclass , ma è piuttosto strano vedere che abstract class Component{} rompe questa definizione.
Con il livello di accesso assegnato a questo metodo public void addNotify() {} , senza conoscere il significato o il significato di questo metodo, vorrei chiedere,
Diventa difficile decidere il livello di accesso di un metodo durante la progettazione della classe come public o protected ?
Perché vorrei dire che in fase di progettazione qualsiasi metodo sarà public in SuperClass solo quando saranno soddisfatte 2 ragioni:
1) Non ci deve essere la necessità di sovrascrivere questo metodo in SubClass in / out del pacchetto, se si tenta di sovrascrivere SuperClass .
2) Sulla base della firma di qualsiasi metodo di livello public , deve essere sicuro dopo aver preso la decisione che questo metodo può essere pubblicamente disponibile, quindi questo metodo non dovrebbe dipendere dall'implementazione in nessun nuovo SubClass in / out del pacchetto. firma nel senso che, ho reso la mia sotto DList di classe disponibile per eseguire l'aggiornamento sequenziale di DList nel tempo O (n), quindi nessun SubClass deve sovrascrivere il prevNode() metodo di DList class. Questo è rischioso !!! Poiché i puntatori prev/next possono essere manipolati qui con una cattiva codifica. Il principio LSK diventerà sicuro.
package DList;/* DList.java */
public class DList {
......
public DListNode prevNode(DListNode node) { /* check this signature*/
if(node.prev != this.sentinel){
return node.prev;
}else{
return null;
}
}
.......
}
/* DListNode.java */
package List;
public class DListNode {
public Object item; /* check this */
protected DListNode prev;
protected DListNode next;
DListNode(Object i, DListNode p, DListNode n) {/* check this signature*/
this.item = i;
this.prev = p;
this.next = n;
}
}
Quindi
Con l'esperienza del codice java scritto, mi sembra facile decidere uno dei due possibili livelli di accesso di tutto il class es / interface design all'interno di un pacchetto.
sembra facile decidere mentre introduce la firma di nuovi metodi,
se un metodo deve avere il livello di accesso private
se un metodo deve avere il livello di accesso package private
Se capisco la domanda seguente, sarebbe facile decidere quando un metodo è protected o public .
1) Perché java consente di sovrascrivere i metodi di livello di accesso public ? Perché è difficile per me decidere quando rendere il mio metodo protected , nonostante io sappia che public è più visibile di protected tra i pacchetti. Si deve prevedere il costo / la conseguenza dell'introduzione di una nuova relazione di ereditarietà prima di assegnare il livello di accesso di protected al metodo del proprio attuale modello di classe.
2) Posso conoscere la risorsa giusta per imparare quando un metodo può essere protected ?
Nota: sono un principiante Java che attualmente comprende l'astrazione / incapsulamento / ereditarietà / polimorfismo e sta per imparare "pacchetto e accesso agli specificatori"