Visualizzazione dei risultati da 1 a 6 su 6
  1. #1
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120

    [java] passare un oggetto che implementa DoubleSupplier a una classe che si aspetta un oggetto che implementa Comparable

    Ciao a tutti,
    ho implementato una coda prioritaria fatta in questo modo :
    codice:
    public class PriorityQueueHeap <E, P extends Comparable<? super P>> implements PriorityQueue<E, P>{...}
    dove E è il tipo dell'elemento, e P è la sua priorità e PriorityQueue è un interfaccia dichiara i metodi generici di una coda qualsiasi.
    Il problema nasce dal fatto che adesso dovrei usare la coda per implementare un algoritmo che lavora su i nodi di un grafo i quali non possono implementare Comparable in quanto non abbastanza restrittivo.
    Infatti gli oggetti che dovrei usare per la priorità devono poter essere comparati esclusivamente in base a un valore double dato da getAsDouble() dell'interfaccia DoubleSupplier e non da un generico criterio dato dall'implementazione di Comparable.
    La cosa più banale sarebbe scrivere una coda esclusivamente per questo caso che prende come priorità oggetti P extends DoubleSupplier e fare tutti i confronti con >, <, = inceve che con il compareTo, solo che non mi sembra la soluzione migliore.
    Quindi mi chiedevo se c'è un modo per poter cambiare la coda in modo da riuscire a gestire anche questo particolare caso, ad esempio sfruttando i comparatori (con i quali non ho molto confidenza).
    Grazie in anticipo per qualsisi aiutao potrete darmi
    La Guida Galattica è infallibile.
    È la realtà, spesso, ad essere inesatta.

  2. #2
    Utente di HTML.it L'avatar di Alex'87
    Registrato dal
    Aug 2001
    residenza
    Verona
    Messaggi
    5,802
    Forse non ho capito bene ma te la butto lì, magari ti va bene.

    Non potresti far implementare ai nodi Comparable<DoubleSupplier> in modo da poter utilizzare getAsDouble() da dentro il compareTo?
    SpringSource Certified Spring Professional | Pivotal Certified Enterprise Integration Specialist
    Di questo libro e degli altri (blog personale di recensioni libri) | ​NO M.P. TECNICI

  3. #3
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    Infatti gli oggetti che dovrei usare per la priorità devono poter essere comparati esclusivamente in base a un valore double dato da getAsDouble() dell'interfaccia DoubleSupplier e non da un generico criterio dato dall'implementazione di Comparable.

    La cosa più banale sarebbe scrivere una coda esclusivamente per questo caso che prende come priorità oggetti P extends DoubleSupplier e fare tutti i confronti con >, <, = inceve che con il compareTo, solo che non mi sembra la soluzione migliore.
    Io vorrei (far) ragionare su un aspetto che forse non hai considerato. Se nella tua collezione PriorityQueueHeap hai gli oggetti di "dato" e distintamente i valori per la "priorità", vuol dire che nella struttura dati devono essere mantenuti e ottenibili in qualunque momento entrambi.
    Infatti ogni volta che aggiungi un nuovo dato e la sua priorità, devi andare a fare tutta una serie di comparazioni per stabilire dove il nuovo dato va inserito per mantenere coerente il criterio di priorità.

    Quindi la domanda è: vuoi mantenere il valore ottenuto subito da getAsDouble() oppure vuoi mantenere l'oggetto DoubleSupplier? Perché se mantieni l'oggetto DoubleSupplier, il valore double fornito non deve cambiare. E siccome il concetto di non-mutabilità non è intrinseco di DoubleSupplier (dipende dalla implementazione, può fornire un valore fisso, una sequenza, valori casuali, ecc...), questa non mi pare una buona soluzione.
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  4. #4
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120
    Grazie per la risposta ma mi è stato imposto dall'alto di non implementare Comparable nel grafo.
    Provo a spiegarmi meglio:
    ho un grafo fatto in questo modo:
    codice:
    public class SparseGraph<V, E extends DoubleSupplier> implements Graph<V, E>{...}
    dove V è il tipo dei vertici (nodi) e E è il tipo dell' arco che fra le altre informazioni contiene un valore Double che rappresenta il suo peso.
    codice:
    e poi la coda:
    public class PriorityQueueHeap<E, P extends Comparable<? super P>> implements PriorityQueue<E, P> {...}
    dove E è il tipo di elemento e P la sua priorità.
    Adesso dovrei inserire all' interno della coda i vertici del grafo come elementi della coda e il valore Double dell'arco(o tutto l'arco) come priorità della coda.
    Il problema è che la coda si aspetta che l'oggetto da usare come priorità implementi Comparable.
    La definizione di grafo non posso modificarla, invece posso cambiare come voglio la coda.
    Dando un occhiata al codice di PriorityQueue di Java ho capito che potrei risolvere scrivendo un costruttore che prenda anche un Comparator e dopo decidere se fare i confronti con Comparable o Comparator come qui: http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/PriorityQueue.java#PriorityQueue.siftDown%28int%2C java.lang.Object%29)
    Dunque nel mio caso potrei passare un comparatore che confronta i getAsDouble di DoubleSupplier.
    Solo che non mi torna una cosa dell'implementazione della coda di Java: non mette restrizioni al tipo E dell'elemento, e se c'è il Comparator usa quello, altrimenti fa un cast a Comparable. Ma come fa a determinare che E sia castabile a Comparable? lo fa sulla fiducia sperando di non lanciare un eccezione?

    EDIT
    @Andbin non avevo visto il tuo messaggio. Per me è fondamentale poter modificare il valore della priorità di un elemento già presente nella coda. È il motivo che mi ha spinto ad usare una mia implementazione invece che quella fornita da Java
    Ultima modifica di Nikopol; 25-08-2015 a 15:51
    La Guida Galattica è infallibile.
    È la realtà, spesso, ad essere inesatta.

  5. #5
    Utente di HTML.it L'avatar di andbin
    Registrato dal
    Jan 2006
    residenza
    Italy
    Messaggi
    18,284
    Quote Originariamente inviata da Nikopol Visualizza il messaggio
    Per me è fondamentale poter modificare il valore della priorità di un elemento già presente nella coda.
    Quindi con lo stesso oggetto DoubleSupplier, il valore fornito da getAsDouble() può cambiare? O invece vai a settare tu un altro oggetto DoubleSupplier?
    Andrea, andbin.devSenior Java developerSCJP 5 (91%) • SCWCD 5 (94%)
    java.util.function Interfaces Cheat SheetJava Versions Cheat Sheet

  6. #6
    Utente di HTML.it L'avatar di Nikopol
    Registrato dal
    Jan 2011
    Messaggi
    120
    Il valore ottenuto da getAsDouble(), ovvero il peso dell'arco, non deve mai cambiare, ma una volta inserito nella coda devo poterlo aggiornare senza modificare il valore iniziale.

    EDIT.
    Quindi la domanda è: vuoi mantenere il valore ottenuto subito da getAsDouble() oppure vuoi mantenere l'oggetto DoubleSupplier? Perché se mantieni l'oggetto DoubleSupplier, il valore double fornito non deve cambiare. E siccome il concetto di non-mutabilità non è intrinseco di DoubleSupplier (dipende dalla implementazione, può fornire un valore fisso, una sequenza, valori casuali, ecc...), questa non mi pare una buona soluzione.
    Ora ho capito! Non ha senso cambiare la coda per fargli accettare un DoubleSupplier. L'unico dato che mi serve per stabilire la priorità è il double che restituisce getAsDouble(). Quindi bastava creare la coda con parametri <V, Double> ; io invece mi arrampicavo sugli specchi per passare a tutti i costi un DoubleSupplier.
    Mi son perso in un bicchiere d'acqua...
    Grazie mille per l'aiuto
    Ultima modifica di Nikopol; 25-08-2015 a 17:17
    La Guida Galattica è infallibile.
    È la realtà, spesso, ad essere inesatta.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.