[Java] implementazione interfaccia

[71104]

in Java, quando implemento un'interfaccia, i metodi che implemento devono avere visibilità per forza pubblica?

considerando che ho una classe che oltre che implementare un'interfaccia eredita già da un'altra classe base (e quindi non posso trasformare l'interfaccia in una classe base astratta con metodi non pubblici), esiste un modo per far si' che i metodi implementati dall'interfaccia siano protetti e non pubblici?

[DanieleC88]

No, mi sa proprio di no:
Nel linguaggio Java, i metodi hanno implicitamente e forzatamente visibilità public [...]

ciao ;)

[71104]

d'oh :muro:
grazie :cry:

PS: penso che aggiungerò un'altra voce a YourLanguageSucks (http://wiki.theory.org/YourLanguageSucks)
EDIT: fatto.

[andbin]

in Java, quando implemento un'interfaccia, i metodi che implemento devono avere visibilità per forza pubblica?Assolutamente sì. I metodi dichiarati in una interfaccia sono implicitamente public e abstract. Secondo le regole dell'override (che valgono anche quando si implementa un metodo di una interfaccia) il livello di accesso non può essere più "ristretto".

[DanieleC88]

PS: penso che aggiungerò un'altra voce a YourLanguageSucks (http://wiki.theory.org/YourLanguageSucks)
EDIT: fatto.
Ma LOL, l'hai fatto davvero! :asd:

Che poi io sono una pippa in quanto ad OOP, lo ammetto, ma se hai un'interfaccia tra due classi che ti definisce tutti e soli i metodi che necessariamente devono implementare, perché farli privati o protetti? :wtf:

ciao ;)

[khelidan1980]

Ma LOL, l'hai fatto davvero! :asd:

Che poi io sono una pippa in quanto ad OOP, lo ammetto, ma se hai un'interfaccia tra due classi che ti definisce tutti e soli i metodi che necessariamente devono implementare, perché farli privati o protetti? :wtf:

ciao ;)

infatti anche a me sembra proprio sbagliato concettualmente,anzi lo ritengo un pregio,e non un difetto il fatto di doverli dichiarare per forza public

[71104]

[...] perché farli privati o protetti? :wtf: privati infatti non ha senso, ma volevo farli protetti affinché fossero accessibili solo alle classi dello stesso package, nonostante che la classe che li implementa sia pubblica.


infatti anche a me sembra proprio sbagliato concettualmente,anzi lo ritengo un pregio,e non un difetto il fatto di doverli dichiarare per forza public :blah:

[gugoXX]

Dai, aggiungi la sezione sul C#, e metti che non c'e' modo decente di utilizzare operatori matematici (+ - * /) all'interno di un Generics che vorrebbe essere generico applicabile a oggetti che abbiano questi operatori in questione.

Es: Una funzione generica che mi restituisce il valore successivo,
public T Next<T>(T input) where T:??ISommable??
{
return input+1;
}

indipendentemente dal fatto che T sia int, double, decimal, int16, (o piu' logicamente un mio tipo che ha effettuato l'overload di operator+)

____________


Per l'SQL direi

1. la mancanza di supporto standard all'update multicolonna da sorgente, o piu' semplicemente l'update di tabelle in Join.

es: TabellaDest (a,b,c)
TabellaSrc (a,e,f)

Effettuare l'update di tutti i record di Dest la cui chiave (a) sia presente in Src, spostando i valori e,f nelle colonne b,c

In SQL standard devo scrivere la grossissima bruttezza

UPDATE TabellaDest dest
SET b= (SELECT e FROM TabellaSrc src WHERE src.a=dest.a),
c= (SELECT f FROM TabellaSrc src WHERE src.a=dest.a)
WHERE dest.a IN (SELECT a FROM TabellaSrc);


Con la conseguenza che la TabellaSrc viene letta 1 volta per capire quali sono i record di TabellaDest da aggiornare, e acceduta 2 (N) volte per ciascun record trovato. Penoso.

2. Mancanza di operatori di gruppo e finestra standard.
Es: Tabella (a,b,c)
Trovare il record che ha b piu' alto. Eventualmente a parita' di b restituire il record con a(primary key) piu' basso. Dove per record significa che voglio tutti e 3 i valori a,b,c di quel record.

Devo accedere 2 volte alla tabella, quando anche i muli sanno che le operazioni MAX/MIN si risolvono in O(N)

Es2: Trovare i 4 record successivi a partire dal record 18, se io avessi ordinato i record secondo il criterio pippo.
es: paginatori di risultati, che non sono stati inventati dal web... Mancanza ridicola.

3. Mancanza di operatori atomici robusti.
Es: Voglio effettuare l'update di un campo di un record, ma voglio anche sapere che valore c'era prima.
L'istruzione UPDATE da sola non mi aiuta, dato che da standard non mi puo' restitutire quanto richiesto.
Se utilizzo una cascata di
SELECT
UPDATE
in ambiente multiprocess ho perso. Qualcuno tra la SELECT e l'UPDATE puo' mettersi in mezzo e cambiare il valore. Non posso essere certo di avere updatato proprio il valore che ho selezionato.

PS: La mia richiesta non e' fare l'UPDATE solo se il valore che sto aggiornando e' quello che ho letto prima.
La mia richiesta e' fare l'UPDATE SEMPRE, solo vorrei sapere con precisione cosa ho sovrascritto... e' troppo?
Dopo 10 anni che lo uso quasi tutti i giorni, per un linguaggio che si prefigge di essere il verbo universale per i database e' secondo me una vergogna.
Immaginate in banca quanti danni si possono potenzialmente fare a causa di mancanze simili a questa.

PS2: Le transazioni generiche non aiutano. La Select non e' bloccante su nessun database. Meglio, su pochi database la SELECT puo' essere dichiarata bloccante per le scritture di altri processi, ma non e' comunque automatico, occorre prendere determinati accorgimenti, ovviamente diversi per ciascun motore.

Per inziare. Se vedo che viene bene ne tiro fuori altri.

[cdimauro]

Dai, aggiungi la sezione sul C#, e metti che non c'e' modo decente di utilizzare operatori matematici (+ - * /) all'interno di un Generics che vorrebbe essere generico applicabile a oggetti che abbiano questi operatori in questione.

Es: Una funzione generica che mi restituisce il valore successivo,
public T Next<T>(T input) where T:??ISommable??
{
return input+1;
}

indipendentemente dal fatto che T sia int, double, decimal, int16, (o piu' logicamente un mio tipo che ha effettuato l'overload di operator+)
Non ci dormi la notte su questa cosa. :p

Concordo anche sugli altri punti, specialmente su quei difetti dell'SQL (standard, perché bene o male si trovano engine che risolvono tutti o quasi i problemi che hai elencato): per chi lavora da tempo coi database si tratta di mancanze grossolane e... incredibile. Ed è ancora più incredibile pensare che a quasi 40 anni dalla presentazione dell'SQL non siano stati ancora (ufficialmente) risolti. :muro:

[71104]

io non sono esperto di SQL e non lo sono così tanto di C#, fatti un account e edita tu ^^

[cionci]

Ma per il punto UPDATE - SELECT...hanno inventato appositamente i lock ;)

[cdimauro]

Che però ammazza le prestazioni in un sistema transazionale (in particolare quelli con multiversioning dei record).