[JAVA] Come riconoscere se un metodo statico e' chiamato da una sottoclasse?

[lovaz]

Salve a tutti.

Ho il problema in oggetto.
Praticamente ho una superclasse con un metodo statico che,
se non ridefinito nella sottoclasse, deve lanciare una UnsupportedOperationException.

Avevo pensato a un codice tipo
if( !???.getClass().equals(Super.class) )
throws ...
Ma ovviamente non so a cosa "attaccarmi".

Idee?
Grazie dell'attenzione.

[andbin]

Ho il problema in oggetto.
Praticamente ho una superclasse con un metodo statico che,
se non ridefinito nella sottoclasse, deve lanciare una UnsupportedOperationException.

Avevo pensato a un codice tipo
if( !(???.getClass() instanceof Super) )
throws ...
Ma ovviamente non so a cosa "attaccarmi".

Idee?Non ce ne sono ....
Innanzitutto i metodi statici non sono soggetti a "override". Tecnicamente devono seguire comunque le stesse regole dell'override ma si parla di "hiding" invece di override.
Quando si invoca un metodo statico o lo si invoca usando il nome della classe o usando un reference (ma in tal caso conta solo ed esclusivamente il tipo del reference, non dell'oggetto).

Pertanto, su queste basi, non vedo come si possa fare quello che chiedi.

[AnonimoVeneziano]

Mmm, credo sia anche una cosa sbagliata a livello concettuale.

Una sottoclasse ,per definizione , ha tutte le caratteristiche e funzionalità (metodi e attributi pubblici quindi) della sua superclasse. Togliere un metodo pubblico alla sottoclasse, che è quello che vuoi fare, sarebbe una violazione di questa regola.

E' compito di colui che progetta la sottoclasse decidere se necessita o meno di ridefinire il metodo statico della superclasse (in genere i metodi statici fanno operazioni generiche , non legate all'istanza della classe , quindi è molto meno comune ridefinirli rispetto ai metodi comuni).

Ciao

[lovaz]

Capisco... cerchero' di farlo non statico, ho una mezza idea...
Grazie comunque.

[lovaz]

Mmm, credo sia anche una cosa sbagliata a livello concettuale.
...
Non mi pare :confused:

In pratica il metodo in oggetto fa parte di una classe contenitore, "quasi" un bean,
che voglio de/serializzare in una stringa del tipo
"campo1:campo2:...:campoN"

pensavo di fare un metodo statico
decode(String)
che mi costruisse un oggetto data una stringa.

Voglio (vorrei) pero' impedirne l'uso da parte di una sottoclasse
che aggiunge dei campi, in modo che se il programmatore vuole
questa serializzazione sia obbligato a fare override (o hiding) di questo
metodo (e del corrispondente non statico encode()),
dato che la codifica cambia.

Un esempio (non statico) puo' essere il metodo ListIterator.add(),
che nell'implementazione ritornata da CopyOnWriteArrayList.iterator()
lancia appunto questa eccezione.

[AnonimoVeneziano]

Non mi pare :confused:

In pratica il metodo in oggetto fa parte di una classe contenitore, "quasi" un bean,
che voglio de/serializzare in una stringa del tipo
"campo1:campo2:...:campoN"

pensavo di fare un metodo statico
decode(String)
che mi costruisse un oggetto data una stringa.

Voglio (vorrei) pero' impedirne l'uso da parte di una sottoclasse
che aggiunge dei campi, in modo che se il programmatore vuole
questa serializzazione sia obbligato a fare override (o hiding) di questo
metodo (e del corrispondente non statico encode()),
dato che la codifica cambia.

Un esempio (non statico) puo' essere il metodo ListIterator.add(),
che nell'implementazione ritornata da CopyOnWriteArrayList.iterator()
lancia appunto questa eccezione.

Capisco quello che vuoi fare. In poche parole il metodo statico è un metodo "Factory" .

In genere i metodi Factory hanno proprio il problema di rendere l'ereditarietà difficile.

Le soluzioni che vedo sono due :

1 - O sposti il metodo factory all'esterno della classe creando quindi una classe di supporto tipo "SuperFactory" dentro la quale metti solo metodi statici che sono i factory della classe "Super" . Poi devi invitare chi volesse ereditare dalla classe "Super" (creando una classe "Sub" ad esempio) a farsi una propria "SubFactory" mettendo dentro gli eventuali metodi factory della classe Sub.

2 - Sposti questa funzionalità all'interno di un costruttore che inizializza i vari campi del nuovo oggetto rimuovendo i metodi factory.

Ciao

[lovaz]

Mi e' venuta in mente un'alternativa: mettere come primo "argomento"
della stringa il nome pienamente qualificato della classe da usare,
e nel metodo statico usare questo nome per caricare la classe
(Class.forName) e invocare il costruttore appropriato,
passandogli tutti gli altri campi.
Nel caso qualcosa non funzioni lanciare un'eccezione (es. ClassNotFound...)

In questo caso encode/decode andrebbero bene anche per tutte le sottoclassi,
e potrebbero essere final.

Sbaglio?

[AnonimoVeneziano]

Ma hai veramente bisogno di una cosa così ? Cioè, forse non vedendo il quadro completo del problema che vuoi risolvere non capisco il perchè vuoi usare questo sistema, ma a prima vista sembra un po' macchinoso.

Che motivo hai per non utilizzare un semplice costruttore per la classe?

Ciao

[lovaz]

Praticamente devo salvare lo stato degli oggetti in un file, possibilmente leggibile anche da un umano.
Nel frattempo ho considerato l'idea di usare csv, ma ho trovato solo un driver read-only:
http://csvjdbc.sourceforge.net/

Poi come opzione vorrei mettere la possibilita' di usare JavaDB,
ma non era incluso in Java6? Non lo trovo, e non trovo neanche uno straccio
di guida introduttiva...

[lovaz]

... JavaDB, ma non era incluso in Java6?...
Trovato, pensavo fosse stato integrato meglio (direttamente nel jre)

Daro' un'occhiata al driver csv, magari lo estendo per la scrittura :D

Poi faro' un interfaccia generica su jdbc.