Il reference this

[andbin]

per il secondo costruttore valgono tutte le validazioni del primo

Certo, perché lo ripeto, è solo una invocazione di un altro pezzo di codice.

sai consigliare qualche testo da studiare?

Per me "IL" libro su Java è "Java™ Programming Language, The, 4th Edition", Addison-Wesley Professional, anche se arriva solo fino a Java 5 (è del 2006) ma è ovviamente in inglese e comunque non è "per tutti". Esiste mi pare una traduzione in italiano.

In italiano e recente, ci sono i libri di De Sio che sono ben citati sui forum. Ma non li conosco personalmente.

[Stark89]

Certo, perché lo ripeto, è solo una invocazione di un altro pezzo di codice.


Per me "IL" libro su Java è "Java™ Programming Language, The, 4th Edition", Addison-Wesley Professional, anche se arriva solo fino a Java 5 (è del 2006) ma è ovviamente in inglese e comunque non è "per tutti". Esiste mi pare una traduzione in italiano.

In italiano e recente, ci sono i libri di De Sio che sono ben citati sui forum. Ma non li conosco personalmente.

Ti ringrazio, purtroppo il libro in inglese lo dego passare,faccio fatica ad apprendere questi concetti in italiano figuriamoci in inglese,sto studiando proprio l'ultimo di Claudio De Sio

[andbin]

faccio fatica ad apprendere questi concetti in italiano figuriamoci in inglese

La documentazione javadoc (del framework di Java SE o di altre librerie) devi però cercare di leggerla ... senza non si va in generale molto lontano ...

[Stark89]

La documentazione javadoc (del framework di Java SE o di altre librerie) devi però cercare di leggerla ... senza non si va in generale molto lontano ...

Si ho dato un occhio,credo che mi serviranno pii avanti, sono arrivato al l'incapsulamento,dopo aver studiato l'ereditarietà credo di poter iniziare a sviluppare qualcosa,per fare un programma con interfaccia grafica devo conoscere qualche altro argomento?vorrei creare un programma che calcoli il codice fiscale

[andbin]

per fare un programma con interfaccia grafica devo conoscere qualche altro argomento?

Visto che stai ancora studiando le basi di Java, consiglio di lasciar perdere (almeno ancora per un po') le interfacce grafiche. Puoi invece realizzare piccole applicazioni "console" e soprattutto cerca di testare, nel senso di sperimentare, le caratteristiche del linguaggio che man mano incontri.

[Vettel]

E' quindi plausibile pensare ad uno standard come proposto qui sotto? (dubito.., l'avrebbero sviluppato da framework)

public class Abcdefg {
    
    private String a;
    private String b;
    private String c;
    private String d;    
    
    public Abcdefg() {
    System.out.println("Sono il costruttore di default.");
    }
    
    public Abcdefg(String a) {
    this(); // Chiama il costruttore senza parametri
    this.a=a;
    }


    public Abcdefg(String a, String b) {
    this(a); // Chiama il costruttore con un parametro
    this.b=b;
    }
    
    public Abcdefg(String a, String b, String c) {
    this(a,b); // Chiama il costruttore con due parametri
    this.c=c;
    }  
    
    public Abcdefg(String a, String b, String c, String d) {
    this(a,b,c); // Chiama il costruttore con tre parametri
    this.d=d;
    }   
    
    // e via cosi' anche per un evenyuale parametro e,f,g etc..
}

[andbin]

E' quindi plausibile pensare ad uno standard come proposto qui sotto?

Non è uno standard ma un "pattern", un modo di sfruttare i costruttori quando ci sono svariati parametri opzionali.
Ed ha un nome: nel suo libro "Effective Java, 2nd Edition" Joshua Bloch lo chiama il "telescoping constructor pattern" (traducibile in: "costruttori telescopici") in cui ogni costruttore "allunga" di un parametro in più (il "telescopico" è in questo senso, appunto).

E come l'hai scritto tu comunque è, tra l'altro, nel peggiore dei modi. Generalmente quando si usa questo pattern, l'assegnamento ai campi si fa solo nel costruttore più completo (quello con tutti i parametri) e gli altri costruttori fanno solo invocazioni this( .. ) invocando il costruttore con un parametro in più passandogli un valore predefinito (o passando più/tutti gli altri valori predefiniti).

Ma come dice Joshua Bloch, nel Item 2 "Consider a builder when faced with many constructor parameters":

In short, the telescoping constructor pattern works, but it is hard to write client code when there are many parameters, and harder still to read it.

Quindi "funziona", è ok. Ma è meno leggibile e non bisogna esagerare con il numero di parametri opzionali.

E poi:

A second alternative when you are faced with many constructor parameters is the JavaBeans pattern

Ma questo chiaramente ha altri svantaggi: a) richiede che l'oggetto sia "mutabile" (non si può fare se deve essere immutabile) e b) lo stato dell'oggetto non è subito ben definito, poiché richiede più setter da invocare e quindi ci possono essere errori dovuti ad un cattivo uso, anche solo per svista del programmatore.

Come ultima/ulteriore alternativa:

Luckily, there is a third alternative that combines the safety of the telescoping constructor pattern with the readability of the JavaBeans pattern. It is a form of the Builder pattern

Questo è assolutamente valido, specialmente se l'oggetto deve essere immutabile. Ma richiede più codice per implementare il Builder (che tipicamente è una public nested class interna alla classe da gestire).