Le variabili locali vengono cancellate dopo l'esecuzione della funzione?

[MItaly]

Anche qui, le performance c'entrano molto poco.
public e private servono a separare quella che è l'interfaccia dell'oggetto (come lo vede il "mondo esterno", e quindi qual è il "contratto" con il resto del codice) e cosa è dettaglio implementativo. L'idea è che tutto ciò che è private lo posso cambiare come mi pare (a patto che la funzionalità rimanga la medesima) e nessuno al di fuori della classe se ne accorge, mentre se modifico qualcosa che è public rompo la compatibilità con il resto del codice. Analogamente, vedendo la questione "da fuori", so che posso usare ciò che è public, mentre ciò che è private non mi riguarda e lo devo lasciare stare (questo è imposto in numerosi linguaggi, mentre è solo suggerito in linguaggi come Python, dove c'è semplicemente la convenzione che i membri che iniziano con un underscore sono membri privati*).

L'idea di fondo è che è difficile scrivere codice affidabile se lo stato di un oggetto (=i valori che possono assumere i suoi campi) può cambiare in maniera completamente libera, ovvero se "dall'esterno" è possibile pasticciare i campi in qualunque maniera. Se invece la modifica dello stato della classe è ristretta ai soli metodi pubblici, è più facile scrivere una classe "a prova di bomba", ovvero che non si possa mai trovare in stati non validi, imprevisti o incoerenti. Torna anche l'idea dell'accoppiamento tra blocchi di codice "lontani": se tutto quello che può modificare i campi privati direttamente sono giusto i metodi d'istanza della classe, allora è relativamente facile prevedere cosa può succedere, capire i problemi che eventualmente si verificano e aggiungere controlli sulle modifiche che vengono fatte dall'esterno, mentre se tutti possono mettere mano a tutto si aumenta l'accoppiamento tra parti lontane di codice, che rende molto più complessa la comprensione e il debugging del programma.

Originariamente inviato da American
ah allora indirettamente già programmo ad oggetti in quanto faccio sempre uso di funzioni..

Non è detto, di base la programmazione "con le funzioni" è programmazione procedurale (anche se è vero che la notazione ad oggetti in genere è in gran parte "zucchero sintattico").

---

* in realtà i nomi con due underscore sono soggetti a name mangling, che li rende "più difficili" da chiamare dall'esterno, il che in un certo senso gli dà una protezione alla "private" di altri linguaggi.

[Scara95]

Leggi questo: Information hiding

[American]

Ho seguito un po' di testi riguardanti la programmazione ad oggetti (nello specifico incentrati su Java).
Posso comunque dire che, guardando sempre al lato dello spreco di risorse, c'è qualcosa che non mi torna nell'intera faccenda legata all'ereditarietà.
Tralasciando le varie classi create da un utente, che possono più o meno essere ottimizzate, vediamo come è strutturato lo stesso linguaggio java...

Ciascuna classe è sempre ereditata dalla classe Oggetto, cioè, se io creo una classe class casa, questa eredita tutti i metodi ed attributi specifici della classe Object
http://docs.oracle.com/javase/1.4.2/...ng/Object.html

Ma se io non prevedo di utilizzare molti dei metodi e degli attributi specifici della classe Object, il fatto di averli solo "istanziati" non rappresenta un inutile spreco di memoria?
Già durante l'esecuzione di un semplice programma dove magari viene "printato" a schermo una parola ed un numero int, entrano in gioco un'infinità di metodi e attributi specifici delle classi string, number e object, figuriamoci in gerarchie di classi molto più profonde

[MItaly]

Uhm, perché pensi che avere tanti metodi corrisponda ad uno spreco di memoria in ogni oggetto? Non è che il codice di ciascun metodo (e ciascuna property, che di fatto è una coppia di metodi sotto mentite spoglie) viene incorporato in ogni oggetto... Di base un oggetto necessita di contenere soltanto i campi (le "variabili membro" che contengono effettivamente dati) e eventualmente la vtable, tutto il resto è zucchero sintattico per chiamate a funzione.

Ora, in C++ se un oggetto non ha metodi virtuali non serve neanche la vtable - tutte le chiamate ai metodi sono risolte a compile-time, per cui non è necessario che l'oggetto si tiri dietro nulla di più dei suoi campi; se invece ci sono metodi virtuali (e in Java se non erro tutti i metodi sono virtuali) ed è necessario avere informazioni sul tipo a runtime (e Java ha potenti funzionalità di reflection) basta che ogni oggetto contenga giusto un puntatore in più ad una struttura dati che identifichi univocamente il tipo dell'oggetto (per la reflection) e contenga tutti i puntatori a funzione necessari per implementare le funzioni virtuali. Per questo motivo, ci sarà una singola istanza per tipo di ciascuna di queste strutture, a cui tutti gli oggetti di quel tipo puntano; ergo, il costo in termini di memoria per implementare funzioni virtuali e reflection è di un "metaoggetto" per ogni tipo definito e di un puntatore per ciascuna istanza del tipo; ergo, è tutta roba piuttosto economica.

(poi in Java c'è di mezzo anche la questione del bytecode e compagnia che rende il tutto un po' meno diretto rispetto all'implementazione C++, ma guardando il bytecode Java che implementa le chiamate a metodi, tutto fa pensare ad un approccio classico "a vtable")

Inoltre, tieni conto che in Java i tipi primitivi (int, long, double, ...) sono una cosa a parte rispetto alla gerarchia degli oggetti ("int" non è una classe, né eredita da Object), sia per ragioni di performance (allocare roba nell'heap ogni volta che si vuole un int sarebbe uno spreco ridicolo), sia per ragioni di semantica (nessuno si aspetta che gli int abbiano semantica per riferimento).

[American]

Quindi se non ho capito male le classi ereditano soltanto i metodi che gli attributi che si ritrovano effettivamente ad utilizzare, attraverso un processo di "scrematura" che viene fatto in fase di compilazione?

Però tanto per dire, aldilà dei metodi e delle vaiabili, c'è anche tutta la questione legata agli event listeners, di questi più se ne istanziano più occupano memoria no?
Non so nemmeno se esistono, ma non ci sono classi che di default dichiarano automaticamente una serie di eventi e di conseguenza ci si ritrova la memoria inzozzata da eventi, tanti per ogni istanze della classe dichiarata?

[MItaly]

Quindi se non ho capito male le classi ereditano soltanto i metodi che gli attributi che si ritrovano effettivamente ad utilizzare, attraverso un processo di "scrematura" che viene fatto in fase di compilazione?

No, il punto è che ereditare metodi non fa consumare memoria se non qualcosina in un'unica struttura dati condivisa tra tutte le istanze di una determinata classe.

Però tanto per dire, aldilà dei metodi e delle vaiabili, c'è anche tutta la questione legata agli event listeners, di questi più se ne istanziano più occupano memoria no?

Gli event listeners da quanto ne so sono semplicemente delle classi che implementano una determinata interfaccia per ricevere degli eventi, quindi il costo, in sé, è quello di un normale oggetto; per ulteriori informazioni comunque chiedi nella sezione Java.

Non so nemmeno se esistono, ma non ci sono classi che di default dichiarano automaticamente una serie di eventi e di conseguenza ci si ritrova la memoria inzozzata da eventi, tanti per ogni istanze della classe dichiarata?

Se sono semplicemente classi, allora equivale ad avere un tot di puntatori all'interno della classe, se non ci si assegna niente sono praticamente gratis (4/8 byte per puntatore).

In ogni caso, mi pare che questa discussione sia diventata un minestrone di troppa roba scorrelata. Se hai altri dubbi apri una discussione a parte (una per problema), specificando sempre il linguaggio di riferimento.