Newsgroup: it.comp.java
Titolo: Oggetti statici....

Ciao a tutti,
ho un problema diciamo "teorico".
Praticamente sono in disputa con un mio collega nella organizzazione
delle classi del nostro progetto.
Praticamente ho delle classi in cui ci sono solo metodi.
La mia soluzione era quella di creare un oggetto con i metodi uguali a
tutte le classi ed estendere questo oggetto, poi aggiungendo i metodi
specifici dei singoli oggetti.
Il mio collega ha creato tutti gli oggeti con metodi statici e
avvalorando la propria scelta dicendo che cosě si evita l'allocazione di
spazio dovuta alla new degli oggetti.
Praticamente io ho questo caso 
public class GenericClass {
..
public met1()
public met2()
...
}
public class C1 extends GenericClass {
...
public metProprio1()
..
}
public class Cn extends GenericClass {
...
public metProprio1()
..
}
Mentre il collega preferisce una soluzione del genere
public class C1 extends GenericClass {
...
public static met1()
public static met2()
public static metProprio1()
..
}
public class Cn extends GenericClass {
...
public static met1()
public static met2()
public static metProprio1()
..
}
La generazione di classi č fatta automaticamente quindi non č un
problema di manutenzione di codice ne di tempo di scrivere la classe...
Secondo voi merita scrivere tutti i metodi statici per guadagnare
memoria?
Utilizzando i metodi statici si hanno anche aumenti di prestazioni
giusto?
GRAzie
 
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

E' una domanda molto filosofica. Il secondo modo mi sembra comunque 
disordinato e poco logico, anche se con codice generato automaticamente.
Se uno applica a pieno l'approccio "a oggetti", secondo me, non dovrebbe 
*mai* avere necessità di metodi statici. Questa è la mia tesi abbastanza 
forte ma cui cerco di tenere fede quanto più possibile.
Tuttavia per non cadere nel "ridicolo", dovendo estendere intere 
gerarchie di classi per un metodino usato sì e no due volte, la 
soluzione del metodo static appare più ragionevole.
Per esempio, mi sono ritrovato a dover creare un metodo che dato un int 
mi restituisce un array di byte. Dovrei quindi estendere la classe 
Integer per attaccarle il mio metodo toArray() e poi usare la nuova 
classe ovunque io abbia bisogno di trasformare un integer?!
L'approccio è corretto sul piano formale ma inapplicabile con la 
ragionevolezza imposta da un codice che sia poi anche leggibile.
Alla fine questi pochi casi sparsi vanno nella classe Util e vengono 
richiamati dove serve con istruzioni del tipo Util.metodoStatico(dati).
Per quanto riguarda l'uso di memoria, se non sbaglio, i metodi statici 
vanno nella memoria "stack" mentre quelli istanziati dinamicamente vanno 
in "heap". C'è da dire che Java, quando istanzia un oggetto, non ricrea 
in memoria tutti i metodi ma solo le variabili. I metodi sono solo 
puntatori al codice originario presente comunque in memoria (stack?). 
Quindi il risparmio può in molti casi essere trascurabile.
Nota finale: una classe non è una libreria di metodi (salvo il mio 
citato esempio della classe Util) ma la codifica di una entità logica 
del programma, che si porta dietro le variabili (che contraddistinguono 
l'entità dai suoi eventuali cloni) ed i metodi necessari a manipolarle.
Alex.

Si è una questione abbastanza "di principio" più che di
 reali differenze nello sviluppo.
Sono d'accordo con te nell'evitare di estremizzare la programmazione ad
oggetti...
 anch'io preferisco, ove possibile, la leggibilità del codice
Grazie della risposta......


 GRAzie
Non credo proprio, magari è l'esatto opposto.
Fate un po' di profiling e illuminateci.
Ciao.

Ok...
se verremo a capo di quesa "disputa" da un punto di vista di performance
 lo farò sapere....
Grazie


 
Il metodo del tuo amico è semplicemente non polimorfico.
Nel senso che non puoi utilizzare i metodi delle sottoclassi avendo
istanze della classe generica e quindi devi in ogni momento sapere che
classi devi usare.
La tua soluzione è senza dubbio migliore.
I metodi statici si utilizzano se non deve essere mantenuto uno stato
(ma allora non ha senso estendere una classe).
Mettere in una classe un metodo statico con lo stesso nome del metodo
statico della classe specializzata è secondo me sbagliato (ovviamente
funziona) ma non è un bell' esempio di programmazione.

 writes:
Scusate il ritardo nella risposta, ma sono stato lontano dalla
possibilità di collegarmi...
A> Per quanto riguarda l'uso di memoria, se non sbaglio, i metodi
A> statici vanno nella memoria "stack" mentre quelli istanziati
A> dinamicamente vanno in "heap".
Sullo stack ci vanno le variabili locali dei metodi, il codice se non
erro va nel segmento text e nello heap ci vanno gli oggetti creati
dinamicamente.
Per l'uso della  memoria, se io replico N volte un  metodo in N classi
userò N  x dimensione_metodo  byte ed anche  i metodi  statici possono
essere ereditati.
Quanto alle prestazioni,  non è lo static ad  influire, se non ricordo
male un articolo del 1995, ma casomai il qualificatore final.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software