Torna indietro   Hardware Upgrade Forum > Software > Programmazione

Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce
REDMI Note 17 Pro porta in fascia media una batteria da 8.340 mAh con ricarica HyperCharge a 67W, un display AMOLED da 6,83 pollici capace di picchi di luminosità molto elevati e una struttura certificata TÜV SÜD contro cadute e infiltrazioni d'acqua, il tutto racchiuso in una scocca da 223 grammi. Lo abbiamo provato per diversi giorni tra fotocamera, prestazioni, autonomia e prezzo sul mercato italiano
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema
Insta360 Luna Ultra integra un sensore da 1 pollice 8K, ottiche Leica e triplo chip IA. Tra schermo OLED rimovibile, workflow I-Log a 10 bit e stabilizzazione a tre assi, analizziamo le doti tecniche di una gimbal camera pensata per i professionisti
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa
Marvel's Wolverine porta Logan in un'avventura inedita, violenta e fortemente narrativa, costruita attorno alla sua natura di combattente e al difficile rapporto con il proprio passato. Insomniac Games punta su combattimenti spettacolari, progressione e personalizzazione, inserendo l'azione in un mondo segnato dalla persecuzione dei mutanti. Un viaggio intenso, che alterna mattanza, esplorazione e momenti sorprendentemente emotivi.
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 16-05-2009, 16:21   #1
D4rkAng3l
Bannato
 
Iscritto dal: Mar 2004
Città: Roma
Messaggi: 2688
[JAVA] Esempio di classe Abstract...ma così non è una porcata?!?!

Ciao,
stavo vedendo un esempio di classe Abstract sul mio libro...ma sinceramente mi pare un po' una porcata come viene usata in questo caso...mi dite se oggettivamente sono cose da evitare o se invece non ho capito bene io?

Praticamente ho una classe astratta IntSet che mi fornisce una rappresentazione parziale di un insieme di interi e l'unica variabile di istanza è la variabile protected dimensione che indica la dimensione di tale insieme di interi.

Poi estendo tale classe abstract mediante la sottoclasse SortedIntSet che rappresenta un insieme di interi ordinati e che usa come variabile di istanza una OrderedIntList (una classe che mi rappresenta liste di interi ordinate).
In tale sottoclasse viene fornita la rappresentazione vera e propria del tipo di dati (che nella classe astratta non veniva fornita perchè poi magari potrei avere altre estensioni di IntSet che la implementano in altro modo...tipo ad esempio un'altra sottoclasse ConstantIntSet che rappresenta insiemi di interi di dimensione costante).

La variabile di istanza dimensione della superclasse è stata definita protected così quando ad esempio aggiungo con il metodo insert() o rimuovo con delete() un elemnto ad OrderedIntList posso accedere alla variabile protected dimensione ed aggiornarla.
Ma francamente mi pare un po' una porcata dichiarare tale variabile protected per 2 motivi:

1) Se cambio l'implementazione della superclasse devo cambiare l'implementazione delle varie sottoclassi.
2) Motivi di sicurezza perchè è visibile in tutto il package e qualsiasi metodo definito nel package potrebbe andare a modificarla.

Che mi dite in proposito? C'ho ragione io o mi sfugge qualcosa?

Il codice d'esempio del libro (parzialmente implementato) è il seguente:

Codice:
public abstract class IntSet{
	
	protected int dimensione;			// La dimensione
	
	// COSTRUTTORE
	public IntSet(){
		dimensione = 0;
	}
	
	// METODI ABSTRACT
	public abstract void insert(int x);		// Inserisce l'elemento x nell'insieme di interi
	public abstract void remove(int x);		// Rimuove l'elemento x dall'insieme di interi
	public abstract Iterator elements();	// Per enumerare gli elementi dell'insieme di interi
	
	
	// METODI IMPLEMENTATI
	public boolean isIn(int x){
		Iterator g = elements();
		Integer z = new Integer(x);
		
		while(g.hasNext())
			if(g.next().equals(z)) return true;
		return false;
	}
	
	public int size(){
		return dimensione;
	}
	
	// IMPLEMENTAZIONE DEI METODI subset() e toString()
}
Codice:
public class SortedIntSet extends Inset{
	
	private OrderedIntList els;
	
	public SortedIntSet(){			// COSTRUTTORE
		els = new OrderedIntList();
	}
	
	public int max() throws EmptyException{
		if(dimensione == 0) throw new EmptyException("SortedIntSet.max");
		return els.greates();
	}
	
	public Iterator elements(){
		return els.elements();
	}
	
	public boolean subset((SortdIntSet) s){
		try{
			return subset((SortedIntSet) s);
		}catch(ClassCastException e){return super.subset(s);}
	}
	
	public boolean subset(SortedIntSet s){
		.....
		.....
		.....
	}
	
	// Implementazione di insert e remove va quì
}
Poi ho qualche domanda teorica:

1) Estendendo IntSet la variabile protected dimensione viene ereditata in SortedIntSet...se si...perchè allora devo dichiararla protected per potervi accedere dalla classe figlia? Se era dichiarata private e viene ereditata perchè non ci si accede automaticamente?

2) Il costruttore della classe abstract IntSet non viene mai invocato dagli utenti ma da quello che ho letto sul libro i costruttori delle classi abstract vengono invocati dai costruttori delle classi che le estendono per inizializzare la parte comune di rappresentazione, giusto?
Allora quì (nel costruttore di SortedIntSet):

Codice:
public SortedIntSet(){			// COSTRUTTORE
		els = new OrderedIntList();
	}
dove cavolo viene invocato il costruttore della classe padre IntSet? Lo fà in automatico senza dover specificarlo? potevo anche metterci dentro super()?

3) Avrei potuto non usare la classe padre abstract (IntSet) ed al posto di questa usare un'interface IntSet senza NESSUNA RAPPRESENTAZIONE (la variabile dimensione) ed implementare vari sottotipi di IntSet tra cui ad esempio il SortedIntSet visto prima ed un ConstantIntSet ognuno con una sua propria rappresentazione e l'implementazione di tutti i metodi abstract definiti dentro l'interface IntSet, avrebbe avuto più senso o no?

4) [DOMANDA FORSE DELIRANTE] Se proprio avessi voluto usare la classe abstract come ha fatto lui nell'esempio del codice, a questo punto non sarebbe stato meglio dichiarare private la variabile di istanza dimensione (nella classe abstract) e poi prevedere in tale classe un metodo abstract che mi faceva accedere a tale variabile (così tale metodo era visibile anche nelle classi figlie)...cambiava qualcosa o no?

Grazie
Andrea
D4rkAng3l è offline   Rispondi citando il messaggio o parte di esso
Old 16-05-2009, 19:31   #2
Energy++
Senior Member
 
Iscritto dal: Oct 2005
Messaggi: 1060
Quote:
Originariamente inviato da D4rkAng3l Guarda i messaggi
Ciao,
stavo vedendo un esempio di classe Abstract sul mio libro...ma sinceramente mi pare un po' una porcata come viene usata in questo caso...mi dite se oggettivamente sono cose da evitare o se invece non ho capito bene io?

Praticamente ho una classe astratta IntSet che mi fornisce una rappresentazione parziale di un insieme di interi e l'unica variabile di istanza è la variabile protected dimensione che indica la dimensione di tale insieme di interi.

Poi estendo tale classe abstract mediante la sottoclasse SortedIntSet che rappresenta un insieme di interi ordinati e che usa come variabile di istanza una OrderedIntList (una classe che mi rappresenta liste di interi ordinate).
In tale sottoclasse viene fornita la rappresentazione vera e propria del tipo di dati (che nella classe astratta non veniva fornita perchè poi magari potrei avere altre estensioni di IntSet che la implementano in altro modo...tipo ad esempio un'altra sottoclasse ConstantIntSet che rappresenta insiemi di interi di dimensione costante).

La variabile di istanza dimensione della superclasse è stata definita protected così quando ad esempio aggiungo con il metodo insert() o rimuovo con delete() un elemnto ad OrderedIntList posso accedere alla variabile protected dimensione ed aggiornarla.
Ma francamente mi pare un po' una porcata dichiarare tale variabile protected per 2 motivi:

1) Se cambio l'implementazione della superclasse devo cambiare l'implementazione delle varie sottoclassi.
2) Motivi di sicurezza perchè è visibile in tutto il package e qualsiasi metodo definito nel package potrebbe andare a modificarla.

Che mi dite in proposito? C'ho ragione io o mi sfugge qualcosa?
si, credo sarebbe stato meglio dichiarare la variabile come private e poi creare dei metodi di accesso e modifica (set, get)

Quote:

Il codice d'esempio del libro (parzialmente implementato) è il seguente:

Codice:
cut..
Codice:
cut..
Poi ho qualche domanda teorica:

1) Estendendo IntSet la variabile protected dimensione viene ereditata in SortedIntSet...se si...perchè allora devo dichiararla protected per potervi accedere dalla classe figlia? Se era dichiarata private e viene ereditata perchè non ci si accede automaticamente?
le variabili e i metodi dichiarati private non hanno visibilità fuori dalla classe di appartenenza:

Accesso privato: si può accedere solo dall’ambito della stessa classe
Accesso pubblico: Completamente disponibile per qualsiasi altra classe che voglia farne uso
Accesso protetto: visibile dalle sottoclassi e nello stesso package
Accesso di default: visibile nello stesso package

Quote:
2) Il costruttore della classe abstract IntSet non viene mai invocato dagli utenti ma da quello che ho letto sul libro i costruttori delle classi abstract vengono invocati dai costruttori delle classi che le estendono per inizializzare la parte comune di rappresentazione, giusto?
Allora quì (nel costruttore di SortedIntSet):

Codice:
public SortedIntSet(){			// COSTRUTTORE
		els = new OrderedIntList();
	}
dove cavolo viene invocato il costruttore della classe padre IntSet? Lo fà in automatico senza dover specificarlo? potevo anche metterci dentro super()?
la classe IntSet ha un costruttore senza parametri che viene richiamato in modo implicito dai costruttori delle varie classi derivate. In caso di un costruttore con parametri, la sua invocazione deve essere invece esplicita con super()
Energy++ è offline   Rispondi citando il messaggio o parte di esso
Old 16-05-2009, 21:21   #3
Dimension7
Senior Member
 
L'Avatar di Dimension7
 
Iscritto dal: Aug 2007
Città: Viterbo
Messaggi: 2559
Ti è stato già risposto, comunque aggiungo alcune precisazioni:

2)Come dice Energy++ il costruttore viene richiamato implicitamente nei costruttori delle classi derivate: per essere più precisi, questo valer per ogni classe derivata, a prescindere dal fatto che la classe padre sia abstract o meno. Se non ci scrivi niente, il costruttore della classe derivata si comporta come se nella prima riga avesse "super()", se vuoi usare un costruttore diverso da quello a zero argomenti puoi farlo ma dev'essere sempre la prima istruzione del costruttore.

3)Dipende sempre da ciò che ti serve: la classe astratta in genere serve quando si ritiene che alcuni metodi saranno uguali per tutte le classi derivate, mentre altri saranno in comune, quindi saranno dichiarati nella classe astratta. Invece l'interfaccia da un'idea un po' più generica delle funzioni, tra virgolette potremmo dire che sono tutte astratte...
Altra caratteristica è che per usare le classi astratte devi ereditarle (o estenderle, se preferisci dire così), mentre le interfacce si implementano: in Java si può ereditare solo da una classe, ma si posso implementare più interfacce.

4)Come facevi a mettere un metodo abstract che si riferiva alla variabile privata? Essendo abstract non ha corpo, quindi non sai come usarlo, devi implementarlo nella classe figlia... non penso funzionerebbe.
Ora non ricordo precisamente, comunque si usa protected per le classi che dovranno essere derivate per un fatto di semplicità, per usare una variabile private nella classe abstract poi avresti dovuto prevedere un metodo getter concreto nella classe stessa. Ma comunque una variabile protected può essere vista solo nello stesso package, quindi si può optare per la creazione di un package piccolissimo, magari costituito solo dalla classe in questione, ed ecco che la variabile sarà accessibile solo a chi eredita dalla classe.
__________________
Coolermaster Centurion 590 - Asus M4A78PRO - Phenom II 720 - HIS 6950 IceQ X Turbo 2GB - 2x2 Gb Corsair XMMS2 - Crucial MX300 500gb - HD WD 500gb - Asus VW246H - Windows 7 Pro 64bit
Dimension7 è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


Recensione REDMI Note 17 Pro: il midrange con batteria da 8.340 mAh e ricarica veloce Recensione REDMI Note 17 Pro: il midrange con ba...
Insta360 Luna Ultra: la potenza del sensore da 1 pollice incontra la portabilità estrema Insta360 Luna Ultra: la potenza del sensore da 1...
Marvel's Wolverine, la recensione: Logan torna protagonista in un'avventura brutale e intensa Marvel's Wolverine, la recensione: Logan torna p...
DJI Romo 2: tante novità lo rendono un robot completo DJI Romo 2: tante novità lo rendono un ro...
Sony Bravia 9 II: il True RGB alla prova, dove l'LCD sfida l'OLED Sony Bravia 9 II: il True RGB alla prova, dove l...
La Camera USA presenta il conto: i data ...
Non solo EV, ma anche IA: Panasonic inau...
iPhone Duo, il debutto del pieghevole di...
Atlas 960E SuperPoD, la risposta di Huaw...
IA militare e nucleare: esperti USA e ci...
Dieci mini-reattori nucleari in Europa d...
CONTROL Resonant su PC: Path Tracing, Ra...
ColorOS 17 arriva su circa 90 dispositiv...
GTA VI, il multiplayer potrebbe debuttar...
Aggiornamento KB5002914 rompe Excel: ecc...
Processo Huawei a Brooklyn: l'FBI mostra...
WhatsApp introduce nuovi temi per le cha...
NVIDIA, Google e Emerald AI uniscono le ...
iPhone 18 Pro Max, il test sulla vapor c...
Fine estate in giardino: le proposte sco...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 22:34.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Served by www3v