[JAVA] Scrivere una classe java...posso farlo o è una PORCATA?!

[D4rkAng3l]

Allora parte di un vecchio compito dell'esame di linguaggi di programmazione sono questi 2 esercizzi:

Problema 1. Si richiede il progetto di un tipo astratto di dati Articolo che rappresenta e gestisce i
singoli articoli presenti in un negozio. Il tipo di dati Articolo deve rappresentare il nome
dell’articolo (es. sapone) ed il suo costo unitario. Inoltre, ad ogni articolo deve essere associato il
codice dell’articolo: esso è univoco (non esistono due articoli con lo stesso codice). Le operazioni
richieste per il tipo di dati sono quelle di accesso in lettura alle informazioni rappresentate.

Problema 2. Si richiede l’implementazione del tipo astratto Articolo in linguaggio Java.

Il punto 1 non ha nulla a che fare con i tipi abstract...è una pippa mentale della proff di analisi pre implementazione...praticamente vuole che definiamo 3 insiemi.
Un insieme V che descrive gli oggetti rappresentati dal mio tipo di dato. Un insieme O che rappresenta le operazioni su tali oggetti ed un insieme C che rappresenta possibili costanti significative...da questa descrizione insiemistica si passa ad una possibile implementazione della classe in Java...tanto per spiegare meglio (ma non è importante ai fini della domanda) in questo caso io dico:

V(codice_articolo) = {un singolo articolo in vendita in un negozio} dove tra () ho messo "codice_articolo" in quanto ogni articolo DIPENDE dal suo codice che lo identifica univocamente.

O = 1) accesso in lettura al campo nome, 2) accesso in lettura al campo costo, 3) accesso in lettura al campo codice articolo

C = 0 (insieme vuoi --> non ci sono costanti significative da rappresentare nella mia classe)

Passo quindi a sviluppare una possibile implementazione in JAVA, dal fatto che in questo tipo astratto ho V(codice_articolo) si deduce che ogni oggetto dipende da un codice che lo identifica in maniera univoca --> nell'implementazione pratica scelto di rappresentare il codice da attribuire al prossimo oggetto creato tramite una variabile di classe che incremento ogni volta che creo un oggetto.

Ed in pratica il mio codice commentato è questo:

public class Articolo{
	
	/* Dichiaro una variabile int di classe che conterrà l'ID da attribuire al prossimo oggetto di tipo Articolo creato e la
	   inizializzo a 0 perchè così il primo oggetto creato avrà ID pari a 0 */
	
	private static int nextObjectID = 0;
	
	// Variaili di istanza
	
	String nome = null;		// Conterrà il nome dell'articolo rappresentato
	double costo;			// Conterrà il costo dell'articolo rappresentato
	int ID;					// Conterrà l'ID che identifica univocamente l'oggetto creato
	
	/** COSTRUTTORE: Crea un oggetto di tipo Articolo.
		@param name di tipo String
		@param cost di tipo double
		@return il riferimento ad un oggetto di tipo Articolo */
	
	public Articolo(String name, double cost){
		
		nome = name;		// Mette il riferimento alla stringa name nella variabile nome
		costo = cost;		// Copia il valore double di cost dentro la variabile costo
		ID = Articolo.nextObjectID;		// Copia il valore della variabile di classe dentro al campo ID dell'ogetto creato
		
		Articolo.nextObjectID ++;		// Incrementa di 1 la variabile di classe, così il prossimo oggetto che sarà creato avrà l'ID successivo
	}
	
	/* METODI DI ACCESSO */
	
	/** getNome() Restituisce il valore del campo nome dell'oggetto ricevente
		@param void
		@return il riferimento alla stringa nel campo nome dell'oggetto ricevente */
		
	public String getNome(){
		return nome;
	}
	
	/** getCosto() Restituisce il valore del campo costo dell'oggetto ricevente
		@param void
		@return il riferimento al valore double nel campo costo dell'oggetto ricevente */
		
	public double getCosto(){
		return costo;
	}
	
	
	/** getID() Restituisce il valore del campo ID che identifica univocamente l'oggetto ricevente
		@param void
		@return il riferimento al valore int nel campo ID dell'oggetto ricevente */	
	
	public int getID(){
		return ID;
	}

}

Dite che può andar bene? me lo avrebbero dato per buono?
La cosa che mi preoccupa di più è se può essere valida la mia idea di rappresentare l'ID univoco del prossimo oggetto da creare come una variabile di classe intera (nextObjectID) ed assegnare tale valore al campo ID dell'oggetto appena creato, per poi incrementare di 1 la variabile di classe...

Che ne pensate? L'esame è tra pochissimi giorni e sono un bel po' preoccupato...

Grazie
Andrea

[D4rkAng3l]

UP

[oh my god]

intanto "esercizi" e non "esercizzi"

Originariamente inviato da D4rkAng3l

public class Articolo{
	
	/* Dichiaro una variabile int di classe che conterrà l'ID da attribuire al prossimo oggetto di tipo Articolo creato e la
	   inizializzo a 0 perchè così il primo oggetto creato avrà ID pari a 0 */
	
	private static int nextObjectID = 0;
        private static int getNextID(){

         return nextObjectID++;

}
	
	// Variaili di istanza
	
	String nome = null;		// Conterrà il nome dell'articolo rappresentato
	double costo;			// Conterrà il costo dell'articolo rappresentato
	int ID;					// Conterrà l'ID che identifica univocamente l'oggetto creato
	
	/** COSTRUTTORE: Crea un oggetto di tipo Articolo.
		@param name di tipo String
		@param cost di tipo double
		@return il riferimento ad un oggetto di tipo Articolo */
	
	public Articolo(String name, double cost){
		
		nome = name;		// Mette il riferimento alla stringa name nella variabile nome
		costo = cost;		// Copia il valore double di cost dentro la variabile costo
		ID = Articolo.getNextID();		
		
		}
	
	/* METODI DI ACCESSO */
	
	/** getNome() Restituisce il valore del campo nome dell'oggetto ricevente
		@param void
		@return il riferimento alla stringa nel campo nome dell'oggetto ricevente */
		
	public String getNome(){
		return nome;
	}
	
	/** getCosto() Restituisce il valore del campo costo dell'oggetto ricevente
		@param void
		@return il riferimento al valore double nel campo costo dell'oggetto ricevente */
		
	public double getCosto(){
		return costo;
	}
	
	
	/** getID() Restituisce il valore del campo ID che identifica univocamente l'oggetto ricevente
		@param void
		@return il riferimento al valore int nel campo ID dell'oggetto ricevente */	
	
	public int getID(){
		return ID;
	}

}

Dite che può andar bene? me lo avrebbero dato per buono?
La cosa che mi preoccupa di più è se può essere valida la mia idea di rappresentare l'ID univoco del prossimo oggetto da creare come una variabile di classe intera (nextObjectID) ed assegnare tale valore al campo ID dell'oggetto appena creato, per poi incrementare di 1 la variabile di classe...

Che ne pensate? L'esame è tra pochissimi giorni e sono un bel po' preoccupato...

Grazie
Andrea

[^TiGeRShArK^]

x me in questo caso, se vuoi assegnare ad ogni articolo un id univoco, la cosa + pulita è usare un factory pattern.
Questo perchè come al solito non deve essere compito dell'articolo gestire cose che non gli competono, ovvero la generazione dell'id unico, ma dovrebbe essere compito di un "gestore" esterno.
Sinceramente se vi insegnano così a programmare, senza spiegarvi le basi dei design pattern (come hanno fatto con me ai tempi ) non vi serve a moltissimo quando abbandonerete l'ambiente accademico...

[D4rkAng3l]

Originariamente inviato da ^TiGeRShArK^

x me in questo caso, se vuoi assegnare ad ogni articolo un id univoco, la cosa + pulita è usare un factory pattern.
Questo perchè come al solito non deve essere compito dell'articolo gestire cose che non gli competono, ovvero la generazione dell'id unico, ma dovrebbe essere compito di un "gestore" esterno.
Sinceramente se vi insegnano così a programmare, senza spiegarvi le basi dei design pattern (come hanno fatto con me ai tempi ) non vi serve a moltissimo quando abbandonerete l'ambiente accademico...

Guarda...il fatto è che è un esame di linguaggi di programmazione e NON E' UN ESAME DI JAVA...come specificato più volte...la parte di Java è molto marginale in quanto l'80% del programma verte su argomenti teorici (oggi fatto il primo scritto di teoria...spero sia andato bene...)...di Java tratta solo argomenti molto superficiali tanto per vedere in pratica cosa significa programmare OO dopo averlo visto in teoria...alla fine l'esame verte molto di più su altri argomenti come linguaggi assemblativi, proprietà dei vari linguaggi, binding, compilatori, interpreti, JVM, vari tipi di polimorfismo.

La parte di Java è veramente molto limitata ed argomenti come i pattern o altre cose nonc'entrano nulla.

Se ti fissi a pensare che è un esame di Java e dici che è un corso fatto a cazzo....beh sbagli....per il semplice fatto che non è un esam di Java...non ti deve insegnare a programmare veramente in Java...per quello ci sarà un altro corso il prossimo semstre ed almeno altri 2 il prossimo anno...

[banryu79]

Originariamente inviato da D4rkAng3l

La cosa che mi preoccupa di più è se può essere valida la mia idea di rappresentare l'ID univoco del prossimo oggetto da creare come una variabile di classe intera (nextObjectID) ed assegnare tale valore al campo ID dell'oggetto appena creato, per poi incrementare di 1 la variabile di classe...

Si ma se una istanza non viene più usata e viene reclamata dal Garbage Collector non "libera" l'ID usato e quando ne verrà istanziata una nuova ID verrà incrementato di 1.

Certo l'ID per una data istanza sarà comunque "univoco", percui puoi anche creare una variabile di classe di tipo int da incrementare ogni volta che viene creata una nuova istanza.

Certo non è l'ideale, e siccome chiedevi se fare così "è una porcata" la risposta di Tiger calzava a pennello, inutile ribadire che non è un'esame di Java...
Altrimenti da che punto di vista avrebbe dovuto essere "una porcata"?

[D4rkAng3l]

Originariamente inviato da banryu79

Si ma se una istanza non viene più usata e viene reclamata dal Garbage Collector non "libera" l'ID usato e quando ne verrà istanziata una nuova ID verrà incrementato di 1.

Certo l'ID per una data istanza sarà comunque "univoco", percui puoi anche creare una variabile di classe di tipo int da incrementare ogni volta che viene creata una nuova istanza.

Certo non è l'ideale, e siccome chiedevi se fare così "è una porcata" la risposta di Tiger calzava a pennello, inutile ribadire che non è un'esame di Java...
Altrimenti da che punto di vista avrebbe dovuto essere "una porcata"?

Per porcata intendevo se ci fossero potenziali rischi per la sicurezza che non avevo considerato o qualcosa del genere...cmq tanto per far capire il programma del corsoè questo:

Parte prima: Caratteristiche dei linguaggi di programmazione.
Caratteristiche dei linguaggi di programmazione.
Evoluzione dei linguaggi di programmazione.
Sintassi: introduzione alle grammatiche formali.
Interpretazione e traduzione; il concetto di binding. Variabili: tipo, scope, l-value, r-value. Tipizzazione statica e dinamica.
Routines, tecniche di legame dei parametri.
Semantica: assiomatica, operazionale.
Classificazione dei linguaggi rispetto alla struttura run-time.
Strutturazione dei dati: tipi built-in e primitivi, dati aggregati, tipi definiti dall'utente e tipi dati astratti. Type systems: program checking statico e dinamico, tipizzazione forte e type checking, compatibilità di tipi, conversioni, tipi e sottotipi, tipi generici, type systems polimorfici.
Strutturazione della computazione: espressioni, ed assegnazioni, istruzioni condizionali e iterative, routines ed effetti collaterali. Eccezioni. Computazioni event-driven.
Strutturazione del programma: metodi di progetto, concetti di supporto della modularità, caratteristiche del linguaggio per la programmazione in the large, unità generiche.
Linguaggi Object-Oriented: concetti di base di programmazione object-oriented, ereditarietà, polimorfismo, binding dinamico delle funzioni. Ereditarietà e type system.

Parte seconda: introduzione al linguaggio Java
Introduzione al linguaggio Java: programmi, classi, oggetti, applicazioni; metodi e messaggi; information hiding e modificatori di accesso; editing, compilazione ed esecuzione di una applicazione Java.
Struttura di una classe Java: tipi di dato astratti, variabili di istanza e di classe, costruttori, metodi di istanza e di classe.
Progetto di applicazioni Java.
Array, array multidimensionali.


La seconda parte su Java è molto corta e comprende poco più della sintassi base...e per lei conta quasi di più una buona proggettazione in forma insiemistica di sto benedetto tipo di dato astratto...però s'ha da fare anche se la parte più difficileera quella relativa all'esame di oggi sulla prima parte del corso...

Cmq grazie delle info che mi state dando...non andranno sprecate ;-)

[^TiGeRShArK^]

Originariamente inviato da D4rkAng3l

Guarda...il fatto è che è un esame di linguaggi di programmazione e NON E' UN ESAME DI JAVA...come specificato più volte...la parte di Java è molto marginale in quanto l'80% del programma verte su argomenti teorici (oggi fatto il primo scritto di teoria...spero sia andato bene...)...di Java tratta solo argomenti molto superficiali tanto per vedere in pratica cosa significa programmare OO dopo averlo visto in teoria...alla fine l'esame verte molto di più su altri argomenti come linguaggi assemblativi, proprietà dei vari linguaggi, binding, compilatori, interpreti, JVM, vari tipi di polimorfismo.

La parte di Java è veramente molto limitata ed argomenti come i pattern o altre cose nonc'entrano nulla.

Se ti fissi a pensare che è un esame di Java e dici che è un corso fatto a cazzo....beh sbagli....per il semplice fatto che non è un esam di Java...non ti deve insegnare a programmare veramente in Java...per quello ci sarà un altro corso il prossimo semstre ed almeno altri 2 il prossimo anno...

E infatti i design pattern sono assolutamente trasversali e non c'entrano proprio nulla con Java e sono anzi da prevedere in fase di progettazione (o di continous design).
Per me è fatto ad cazzum...
Tanto è vero che nella Bibbia che ogni programmatore dovrebbe avere con sè accanto al comodino, scritto dalla gang of fours:

I pattern sono utilizzati da molti dei migliori programmatori, quali Bruce Eckel, Andrei Alexandrescu ed Herb Sutter, e la loro conoscenza viene solitamente raccomandata a chiunque voglia progettare software a livello professionale, non solamente tramite il paradigma ad oggetti. In effetti i pattern non sono basati su di uno specifico linguaggio di programmazione, anche se nel libro gli esempi di codice sono in C++ e Smalltalk, con alcuni diagrammi di classe di tipo UML.

A maggior ragione un corso che si prefigge di insegnare la progettazione non può prescindere da questi argomenti.
Forse avrei capito di + questa scelta se fosse stato un corso semplicemente improntato su java.

[D4rkAng3l]

Originariamente inviato da ^TiGeRShArK^

E infatti i design pattern sono assolutamente trasversali e non c'entrano proprio nulla con Java e sono anzi da prevedere in fase di progettazione (o di continous design).
Per me è fatto ad cazzum...
Tanto è vero che nella Bibbia che ogni programmatore dovrebbe avere con sè accanto al comodino, scritto dalla gang of fours:

A maggior ragione un corso che si prefigge di insegnare la progettazione non può prescindere da questi argomenti.
Forse avrei capito di + questa scelta se fosse stato un corso semplicemente improntato su java.

WAIT...non voglio contraddirti troppo perchè sei sicuramente molto più esperto di me...ma questo non è neanche un corso di proggettazione (per quello c'è Ingegneria del software ed altri vari esami di Java al terzo anno).

Questo è un corso di linguaggi di programmazione...il progettare in Java non è il nodo fondamentale...Java in questo corso è solo per far vedere cosa significa proggettare ad oggetti...STOP...in tale corso è proprio la programmazione ad avere un ruolo marginale...paradossalmente c'è più assembler di JAVA tra gli argomenti trattati...

Di Java la cosa principale del corso è vedere cosa succede nello STACK e nello HEAP...

Certo che se lo prendi come un esame di programmazione, o ancor peggio di progettazione sarebbe un esame fatto a cappella...ma non è quello...c'è una parte di JAVA ok...ma lo scopo del corso non è quello...tant'è che in questo esame per JAVA si usano solo le dispensine della proff e il libro è questo:


che non c'ha manco mezza linea di codice di JAVA al suo interno...

Poi che ci sia una seconda parte di JAVA scritta è un altro discorso...ma non si può dire che un corsoè fatto alla cazzo perchè molti argomenti di java non sono stati trattati...fosse un esame di java capirei...ma se ti leggi il programma vedi che è solo una piccola parte per dare una prova pratica di argomenti teorici...

Poi vabbè...è una proff che stimo molto (anche se è cagacazzi sotto molti aspetti )...e cmq non è proprio un corso di programmazione nel vero senso della parola...poi vabbè...

[banryu79]

Originariamente inviato da D4rkAng3l

Per porcata intendevo se ci fossero potenziali rischi per la sicurezza che non avevo considerato o qualcosa del genere...

Ah, ok, allora guarda avevo frainteso.