Carmine2898 ha scritto:
ho il "vizio" di non rimanere mai con nessun dubbio, per quanto piccolo esso sia.
E fai bene! Non è certo "negativo".
Carmine2898 ha scritto:
1) Se non viene creato il costruttore lo crea automaticamente Java o Eclipse?
Nel corso che sto seguendo mi è stato detto che Eclipse crea automaticamente un costruttore di default se il programmatore non lo scrive, penso che ciò non sia vero. Ho letto che è Java, in fase di compilazione, a creare il costruttore di default se il programmatore non si è occupato di scriverlo.
Chi dice il vero?
Se non definisci tu alcun costruttore in una classe, viene inserito quello di "default". Ma chi lo inserisce è il
compilatore in fase di compilazione.
Se tu usi (direttamente a mano o con qualche tool) il
javac del JDK, allora stai usando il compilatore del JDK. Se stai usando Eclipse, esso ha un
suo compilatore Java interno. Quindi non è tanto Eclipse come IDE/Editor in sé ma appunto il compilatore Java integrato in Eclipse.
Quindi, ripeto, lo inserisce il compilatore. E dipende appunto da quale compilatore Java si usa.
Carmine2898 ha scritto:
2) I metodi get e set. Mi spiego meglio: so che get restituisce il valore di un determinato campo e che set permette di impostarlo.
Sono metodi che mi permettono di accedere ad attributi privati di una certa classe, la domanda che mi pongo è: che senso ha impostare degli attributi privati se posso comunque accedervi? Sono molto graditi degli esempi pratici sulla questione.
Se usi campi pubblici, non applichi il principio di incapsulamento e questo porta a diversi problemi:
1) Esponi all'esterno una informazione (il fatto di avere un campo chiamato X e di tipo Y) che invece magari potrebbe non essere affatto utile o interessante o necessaria all'esterno.
2) Il campo non lo potrai mai più cambiare. Se avevi un campo
int prezzo; e un giorno ti accorgi che sarebbe meglio
double prezzo; o peggio cambiando pure il nome es.
int prezzoNetto;, NON lo puoi più cambiare, perché potresti "spaccare" chissà quanto altro codice in giro.
3) Non puoi applicare vincoli, quelli che in gergo si dicono "invarianti". Se un campo è pubblico, le istruzioni che fanno
obj.campo = xyz; sono sparpagliate in chissà quanti altri punti della applicazione e magari di cui NON hai il controllo.
Se hai una classe Persona con un campo
public int annoNascita; , NON puoi impedire che "qualcuno" imposti un anno di nascita
negativo. Dalla TUA classe Persona non puoi cioè impedire che qualcuno faccia altrove:
unaPersona.annoNascita = -1;
Se invece tieni il campo private e metti un setter public, puoi fare:
public class Persona {
// ...
private int annoNascita;
// ...
public void setAnnoNascita(int annoNascita) {
if (annoNascita < 0) {
throw new IllegalArgumentException("Anno di nascita non puo' essere negativo");
}
this.annoNascita = annoNascita;
}
}
E in questo modo garantisci che NESSUNO (escludiamo i truschini con la reflection) possa andare a sovvertire questa regola (invariante) di Persona.
Carmine2898 ha scritto:
3) Il metodo printStackTrace(), mi confermate che: stampa lo stack delle funzioni che hanno portato all'eccezione. Serve in fase di debugging per capire dove e perché si è verificato il problema?
Sì, e.printStackTrace() è utile per stampare lo stack trace di una eccezione, tipicamente per debugging. (ma dipende per quale tipo di applicazione. Meglio in generale del logging con librerie apposite)