[Java] Array di Oggetti

[BlackAuron]

Ciao a tutti ... sto cercando di muovere i primi passi con java dopo diverso tempo dedicato al javascript e al c.
Non avendo mai toccato l'idea di classe, o qualche problema a livello "concettuale", ma qua credo che il problema sia un altro, e penso sia dovuto alla dichiarazione dell'Array, ma qualcosa mi sfugge.
Idee?


package Test;

import java.util.*;

public class Contatti {
Contatto Elenco[] = new Contatto[10];
Elenco[0] = new Contatto();
}

class Contatto {
Contatto(){
System.out.println("Costruttore Richiamato");
}

private String name = new String();

public void setName(String s){
name = s;
System.out.println("Name Set");
}
}


--- come non detto, risolto ... era una noobbata

[PGI-Bis]

public class Contatti {
Contatto Elenco[] = new Contatto[10];

public Contatti() {
Elenco[0] = new Contatto();
}
}

Il corpo di una classe può contenere solo dichiarazioni di variabili (o metodi o costruttori o inizializzatori... o un sacco di cose ma non espressioni a meno che non sia parte di un'inizializzazione contestuale alla dichiarazione).

[sprik]

private String name = new String();



Dato che stai cominciando, è buona norma che le inizializzazione di eventuali attributi vadano nel costruttore della classe e non nella dichiarazione.

[PGI-Bis]

Perchè?

[nuovoUtente86]

infatti, perchè?

[sprik]

Ma perchè secondo voi il costruttore a che serve?
Per definizione, il costruttore è un metodo che serve per inizializzare gli attributi di una classe, ecc.

L'inizializzazione degli attributi nella loro dichiarazione è una cosa stile paradigma imperativo, invece, in quello ad oggetti è buona norma inizializzarlo nel costruttore. Poi ognuno lo fa come gli piace, nessuno si lamenta, nemmeno il compilatore!

[nuovoUtente86]

Il costruttore serve ad inizializzare a valori specifici i campi, ma se questi sono comuni per tutti i tipi di istanze creabili, è bene inizializzarli in fase di dichiarazione. Per di più, java, utilizza le inizializzazione di default ed inserisce il costruttore vuoto, in assenza di altre dichiarazioni.

[PGI-Bis]

Le "buone norme" possono essere suggestive ma sono pericolose perchè generalmente non hanno un riscontro obiettivo.

Uno usa o non usa una caratteristica del linguaggio secondo l'aderenza dei suoi presupposti e dei suoi effetti al risultato che vuole ottenere.

Per Java, riguardo all'inizializzazione dei campi, vale quanto segue:

1. se il valore iniziale del campo deve essere quello predefinito -> dichiarazione senza inizializzazione.

2. se il valore iniziale del campo è diverso da quello predefinito e dipende da espressioni computabili a partire dal valore iniziale di campi precedenti o di costanti -> dichiarazione con inizializzazione.

3. se l'espressione di inizializzazione di cui al punto 2 richiede la dichiarazione di variabili computabili a partire da costanti o da valori di altri campi e quelle variabili non sono a loro volta campi -> inizializzazione in un blocco di inizializzazione.

4. se il valore iniziale del campo dipende da valori esterni alla classe dell'istanza inizializzata -> inizializzazione nel costruttore.

La 4 vale anche nel caso in cui la procedura di inizializzazione possa essere decidibile da un sottotipo tramite l'invocazione di supercostruttore alternativo.

E', se vogliamo, un esercizio di sintesi: ripeto, uno scrive quanto è strettamente necessario all'effetto che vuole ottenere.

[sprik]

Alt, voi parlate strettamente di Java...dovreste pensare nell'ottica generale di programmazione ad oggetti.
E' normale che se parlate di java dite "vabbè questo lo posso evitare tanto ci pensa lui, bla, bla, ecc" ma se parlate in un contesto generale, teoria vera e propria di programmazione ad oggetti la cosa cambia.
Se parlate di C++, beh...li l'inizializzazione di quel tipo nn ci sta un po' malino? del resto sfogliando il libro trovate "in C++ è possibile inizializzare una variabile nella sua dichiarazione", e qui di nuovo alt, si parla di variabile, non di attributi.
Per quanto possano essere simili, variabili ed attributi sono cose totalmente diverse.
Poi vabbè, in qualsiasi libro di Java, compresi i miei, trovate le assegnazioni di default, ecc...ma se prendete un libro di teoria di programmazione ad oggetti? beh, le cose cambiano...perciò stiamo attenti a distinguere cosa fa Java e cosa è realmente la programmazione ad oggetti.

[PGI-Bis]

In un topic su Java si suppone che si dia una risposta su Java. Da un punto di vista orientato agli oggetti la questione è irrilevante.

[sprik]

Certo, si dice così per ogni linguaggio.

[khelidan1980]

mah a dire il vero la tendenza ormai è di usare getter e setter,e poi tu dici di fare riferimento alla teoria generale e poi fai esempi con il C++

[sprik]

Con getter e setter tu ti riferisci al name masking che è tutta un'altra cosa, con scopi diversi, che già esisteva prima ancora della programmazione ad oggetti...solo che adesso va di moda.