[Object Orientation] Metodi getter/setter. Che ne pensate?

[ndakota]

Ciao a tutti. All'università sto seguendo il corso di Progettazione del software e ultimamente stavamo parlando di object orientation. Volevo sentire la vostra opinione sui metodi getter/setter. Li usate, preferite un altro metodo o trovate un compromesso? Se usate un altro metodo, quale? Grazie

[shinya]

Personalmente mi sono sempre sembrati una stronzata.
Io tendo a rendere tutto immutabile (ad esempio in java le mie variabili di istanza sono tutte "public final"... dove possibile ovviamente).

[cdimauro]

Preferisco le property, già dai tempi di Delphi.

[ndakota]

Originariamente inviato da shinya

Personalmente mi sono sempre sembrati una stronzata.
Io tendo a rendere tutto immutabile (ad esempio in java le mie variabili di istanza sono tutte "public final"... dove possibile ovviamente).

Anche secondo me sono una stronzata. Però per esempio, con il metodo che dici tu, se un tuo campo lo vuoi far diventare da int a long, hai qualche problema. O sbaglio? Mi riferisco al fatto che sia public.

Originariamente inviato da cdimauro

Preferisco le property, già dai tempi di Delphi.

Cosa sono le property? Per esempio, in Java?

[shinya]

Originariamente inviato da ndakota

Anche secondo me sono una stronzata. Però per esempio, con il metodo che dici tu, se un tuo campo lo vuoi far diventare da int a long, hai qualche problema. O sbaglio? Mi riferisco al fatto che sia public.

Eh? Tipo? Scusa fammi un esempio di come non avresti lo stesso problema con getter/setter...

[ndakota]

Originariamente inviato da shinya

Eh? Tipo? Scusa fammi un esempio di come non avresti lo stesso problema con getter/setter...

No, appunto. Dico che anche quelli non sono la soluzione.

[Kralizek]

Originariamente inviato da cdimauro

Preferisco le property, già dai tempi di Delphi.

vedo le property di delphi e rilancio con le automatic properties di c# 3.0

[ndakota]

Originariamente inviato da Kralizek

vedo le property di delphi e rilancio con le automatic properties di c# 3.0

Tu passi da doghe dei letti ad automatic properties di C#

[Tommo]

Concettualmente sono una stronzata (sono le properties, ne più ne meno), ma in un linguaggio che non offre le properties tipo C++ o Java vanno usati, anche se a malincuore.

Ho provato a "farla semplice" e creare semplicemente membri pubblici, ma questo impedisce qualsiasi controllo su cosa viene settato dall'esterno e quando... e questo manco a dirlo è una fabbrica di bug.

Stesso dicasi per le letture, ad esempio qualcuno potrebbe decidere di prendersi un puntatore al membro, che poi viene invalidato senza che lui lo sappia.

Quindi, in C++/Java, getter e setter vanno usati a forza. In altri linguaggi, fate vobis

PS: mentre in C++ sono spesso inline e quindi non impattano sulle performance, in Java sono vere chiamate a funzione... e quindi oltre al danno, la lentezza!

[banryu79]

Originariamente inviato da Tommo

PS: mentre in C++ sono spesso inline e quindi non impattano sulle performance, in Java sono vere chiamate a funzione... e quindi oltre al danno, la lentezza!

Hai mai provato a vedere il bytecode generato?
No perchè a sentir voi, pare sempre che negli altri linguaggi il compilatore sia furbo mentra javac deve essere per forza una ciabatta che non è capace a ottimizzare roba del genere...

[Kralizek]

Originariamente inviato da ndakota

Tu passi da doghe dei letti ad automatic properties di C#

OT: lol, come ti chiami su tgm?

[ndakota]

Risposta in privato [/OT]

[shinya]

Originariamente inviato da banryu79

Hai mai provato a vedere il bytecode generato?
No perchè a sentir voi, pare sempre che negli altri linguaggi il compilatore sia furbo mentra javac deve essere per forza una ciabatta che non è capace a ottimizzare roba del genere...

A voi!

// H4xx0r.java
class H4xx0r {
  private int leet;

  public int getLeet() { return leet; }
  public void setLeet(int leet) { this.leet = leet; }

  public static void main(String... args) {
    H4xx0r h = new H4xx0r();
    h.setLeet(1337);
    System.out.println(h.getLeet());
  }
}

// H4xx0r2.java
class H4xx0r2 {
  public int leet;

  public static void main(String... args) {
    H4xx0r2 h = new H4xx0r2();
    h.leet = 1337;
    System.out.println(h.leet);
  }
}

// javap -c H4xx0r
Compiled from "H4xx0r.java"
class H4xx0r extends java.lang.Object{
H4xx0r();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."<init>":()V
   4:	return

public int getLeet();
  Code:
   0:	aload_0
   1:	getfield	#2; //Field leet:I
   4:	ireturn

public void setLeet(int);
  Code:
   0:	aload_0
   1:	iload_1
   2:	putfield	#2; //Field leet:I
   5:	return

public static void main(java.lang.String[]);
  Code:
   0:	new	#3; //class H4xx0r
   3:	dup
   4:	invokespecial	#4; //Method "<init>":()V
   7:	astore_1
   8:	aload_1
   9:	sipush	1337
   12:	invokevirtual	#5; //Method setLeet:(I)V
   15:	getstatic	#6; //Field java/lang/System.out:Ljava/io/PrintStream;
   18:	aload_1
   19:	invokevirtual	#7; //Method getLeet:()I
   22:	invokevirtual	#8; //Method java/io/PrintStream.println:(I)V
   25:	return

}

// javap -c H4xx0r2.java
Compiled from "H4xx0r2.java"
class H4xx0r2 extends java.lang.Object{
public int leet;

H4xx0r2();
  Code:
   0:	aload_0
   1:	invokespecial	#1; //Method java/lang/Object."<init>":()V
   4:	return

public static void main(java.lang.String[]);
  Code:
   0:	new	#2; //class H4xx0r2
   3:	dup
   4:	invokespecial	#3; //Method "<init>":()V
   7:	astore_1
   8:	aload_1
   9:	sipush	1337
   12:	putfield	#4; //Field leet:I
   15:	getstatic	#5; //Field java/lang/System.out:Ljava/io/PrintStream;
   18:	aload_1
   19:	getfield	#4; //Field leet:I
   22:	invokevirtual	#6; //Method java/io/PrintStream.println:(I)V
   25:	return

}

[banryu79]

Originariamente inviato da shinya

A voi!
snip...

Ok, è una ciabatta

Scherzi (e svarione mio) a parte, il costo a runtime dei getter/setter è trascurabile, se vengono effettuate poche chiamate.
Se vengono effettuate molte chiamate, la JVM compila il metodo in maniera nativa (normalmente con HotSpot ricordo che se un metodo viene invocato 1000 volte a runtime viene compilato).
Non saprei se al posto della compilazione nativa di un getter/setter liscio sia prevista la possibilità di effettuare un accesso diretto al campo...

Chiaro che se la classe è final e i suoi campi sono immutabili, questi utlimi possono semplicemente essere esposti come pubblici.

In ogni caso, a livello prestazionale, quanto può mai essere rilevante il peso dei getter/setter nella tipica applicazione media per cui viene usato Java?

[shinya]

Originariamente inviato da banryu79

In ogni caso, a livello prestazionale, quanto può mai essere rilevante il peso dei getter/setter nella tipica applicazione media per cui viene usato Java?

Dato che ho qualche minuto di inattività...

// Setters.java
class Setters {
  private double x;

  public void setX(double x) { this.x = x; }

  public static void main(String... args) {
    for (int i = 1; i <= 5; ++i) {
      System.out.print("Try " + i + ": ");
      final Setters victim = new Setters();
      final long start = System.nanoTime();
      
      for (int j = 0; j < 100000; ++j) {
        victim.setX(Math.random());
      }
      System.out.println((System.nanoTime() - start) / 1000000000.0);
    }
  }
}

// NoSetters.java
class NoSetters {
  public double x;

  public static void main(String... args) {
    for (int i = 1; i <= 5; ++i) {
      System.out.print("Try " + i + ": ");
      final NoSetters victim = new NoSetters();
      final long start = System.nanoTime();
      
      for (int j = 0; j < 100000; ++j) {
        victim.x = Math.random();
      }
      System.out.println((System.nanoTime() - start) / 1000000000.0);
    }
  }
}

I risultati sono "meh"...

c:\> java Setters
Try 1: 0.009697214
Try 2: 0.00675697
Try 3: 0.007349395
Try 4: 0.006881777
Try 5: 0.007874961

c:\> java NoSetters

Try 1: 0.014335313
Try 2: 0.006779257
Try 3: 0.006854627
Try 4: 0.007369251
Try 5: 0.006836393

[cdimauro]

Originariamente inviato da ndakota

Cosa sono le property? Per esempio, in Java?

Java non le ha ovviamente, per cui nisba esempi.

Ti evito Delphi e fornisco un esempio semplice in C# direttamente dalla mamma.

Originariamente inviato da Kralizek

vedo le property di delphi e rilancio con le automatic properties di c# 3.0

Beh, io ho detto già ai tempi. Come dire: roba vecchia.

Poi sappiamo pure chi è il papà di C#, no?

Ovviamente son d'accordo con l'evoluzione che hanno preso in C# (ci sono pure le property virtuali ).

Originariamente inviato da Tommo

Quindi, in C++/Java, getter e setter vanno usati a forza. In altri linguaggi, fate vobis

C'è di meglio, appunto.

PS: mentre in C++ sono spesso inline e quindi non impattano sulle performance, in Java sono vere chiamate a funzione... e quindi oltre al danno, la lentezza!

Questo è anche dovuto al fatto che normalmente i metodi in Java sono virtuali, per cui il compilatore non può certo renderli inline come fa il C++, dove sei TU a dichiarare virtuali i metodi se proprio li vuoi così, altrimenti sono assimilabili a delle normali funzioni e quindi il compilatore può rovistarci dentro per capire se può ottimizzare qualcosa.

[Tommo]

@banryu79: lol! A difendere la VM Java si rischia sempre un sacco

@shinya: quel test fa acqua, random è troppo più pesante di una singola chiamata a funzione

Prova a fare l'unroll e usare una roba del genere

for (int i = 1; i <= 5; ++i) {
      System.out.print("Try " + i + ": ");
      final Setters victim = new Setters();
      final long start = System.nanoTime();
      
      int lol = 2389472;

      for (int j = 0; j < 100000; ++j) {
        victim.setX(lol);
        victim.setX(lol);
        victim.setX(lol);
        victim.setX(lol);

        victim.setX(lol);
        victim.setX(lol);
        victim.setX(lol);
        victim.setX(lol);
      }
      System.out.println((System.nanoTime() - start) / 1000000000.0);
    }

vedrai che la differenza si vede!

Comunque, il peso del getter e setter è sicuramente poco, ma in codici compute-intensive è sicuramente meglio non averlo

@cdimauro il NON poter dichiarare qualcosa "non virtuale" invece, prova che Java è un pò una fetecchia...
ma d'altra parte grazie alla mancanza di operator overloading pure le somme tra vettori devono essere una chiamata a funzione virtuale, quindi sta messo male

[cdimauro]

Quello sì, l'overloading è una manna dal cielo (per anni ne ho sentito la mancanza in Delphi).

Però le funzioni non virtuali le puoi dichiarare come static: sono la stessa cosa alla fine.

[demos88]

@Tommo non mi pare che banryu abbia detto castronate
cmq ho provato il tuo codice alzando a 1 miliardo il numero di iterazioni del for: con i setter ho avuto 0.03526231 secondi di media dei 5 try, mentre senza setter ho avuto 0.03517135.
Quindi, su 1 miliardo di iterazioni, il codice coi setter è più lento dello 0,0026% rispetto al codice senza setter, ovvero 91microsecondi (sempre su 1 miliardo di iterazioni).
E' palese che non posso spalmare 91microsecondi su 8 miliardi di set, ciò mi fa dedurre che probabilmente la jvm ottimizzi "strada facendo" e che comunque non ci sia un calo di prestazioni degno di nota. Se mi importasse quel margine di performance, allora farei meglio a passare al C o direttamente all'assembly...

Conclusione: non mi pare si possa dire qualcosa su quanto schifo faccia il java sulla base di questi discorsi. Poi si sa, è solo una questione di simpatia o antipatia personale verso i linguaggi.

[Kralizek]

Originariamente inviato da demos88

@Tommo non mi pare che banryu abbia detto castronate
cmq ho provato il tuo codice alzando a 1 miliardo il numero di iterazioni del for: con i setter ho avuto 0.03526231 secondi di media dei 5 try, mentre senza setter ho avuto 0.03517135.
Quindi, su 1 miliardo di iterazioni, il codice coi setter è più lento dello 0,0026% rispetto al codice senza setter, ovvero 91microsecondi (sempre su 1 miliardo di iterazioni).
E' palese che non posso spalmare 91microsecondi su 8 miliardi di set, ciò mi fa dedurre che probabilmente la jvm ottimizzi "strada facendo" e che comunque non ci sia un calo di prestazioni degno di nota. Se mi importasse quel margine di performance, allora farei meglio a passare al C o direttamente all'assembly...

Conclusione: non mi pare si possa dire qualcosa su quanto schifo faccia il java sulla base di questi discorsi. Poi si sa, è solo una questione di simpatia o antipatia personale verso i linguaggi.

beh oddio... arrivati alla versione 7 potrebbero anche provare a darvi un po' di zucchero sintattico, non fa ingrassare mica...

public class MyClass
{
    public int Id { get; set; }

    private string _name;

    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }
}