1. casa
  2. Domanda e risposta
  3. Perché IntegerProperty implementa la proprietà <Number> e non la proprietà <Integer>?

Perché IntegerProperty implementa la proprietà <Number> e non la proprietà <Integer>?

2016-01-08 9 views
5

L'interfaccia Property aggiunta da JavaFX ha un parametro di tipo T, che è il tipo del valore incluso nella proprietà.Perché IntegerProperty implementa la proprietà <Number> e non la proprietà <Integer>?

Tra le implementazioni dell'interfaccia Property, ci sono alcuni per i numeri: IntegerProperty, FloatProperty, ecc Tutte queste classi implementano Property<Number>.

Prendiamo ad esempio IntegerProperty. Qual è la ragione per cui implementa Property<Number> e non Property<Integer> come mi sarei aspettato?

Ecco un diagramma UML che chiariscono la gerarchia delle IntegerProperty:

enter image description here

fonte

2016-01-08 Paolo Fulgoni

+0

Ho il senso più strano del déjà vu. Hai già fatto questa domanda? – Kayaman

+1

@ Kayaman No, mai chiesto prima. Ho anche fatto del mio meglio per verificare se qualcuno lo ha già fatto. –

+2

Possibilmente implementato in questo modo per semplificare il binding delle proprietà del numero. Vedi http://stackoverflow.com/q/28179293/1288408 –

risposta

5

Come menzionato nella sezione commenti di un bug report Java (DoubleProperty has unexpected generics type),

Questo progetto è destinato. Mantiene il numero di metodi richiesti significativamente più piccoli.

Nei commenti di questa risposta, James_D mi ha reso consapevole di un bug report in seguito rivolgendosi tale questione, ChangeListener cannot be added to SimpleIntegerProperty). Il commento

Abbiamo deciso di non modificare i generici delle proprietà dei tipi primitivi (da Numero a tipo specifico) a causa di problemi di compatibilità con le versioni precedenti. Tuttavia, significa che questo problema non può essere risolto.

suggerisce che il team ha preso in considerazione la modifica del progetto, ma era troppo tardi.

fonte

2016-01-08 11:53:05

+3

Devo dire che sono d'accordo con il commento di Randahl Isaksen: "Tuttavia, per me questo sembra essere un uso improprio di generici. i generici si aspetteranno che un FruitCrate che utilizza i generici sia una cassa non una cassa . L'intero scopo dell'utilizzo di generici è quello di garantire la sicurezza del tipo di tempo di compilazione e meno il casting. Con questo modello, non è possibile garantire pienamente l'uso corretto dei tipi durante la compilazione tempo e hai ancora bisogno di casting Sono consapevole che questo design può semplificare internamente la tua API, ma esternamente, questo diminuisce la qualità dell'API JavaFX. " – Itai

+3

In molti commenti successivi dal team di sviluppatori JavaFX (vedi ad esempio http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-February/012739.html) si iniziano a vedere i riferimenti a "abbiamo provato a risolvere questo, ma era troppo tardi ", il che mi suggerisce che, sebbene possa essere stato previsto, è stato un errore. Esistono altre soluzioni che non implicano l'esplosione combinatoria dell'API, ad es. 'public abstract class NumberProperty implements Proprietà ' e 'public class IntegerProperty estende NumerProperty ', come suggerito da un numero di persone. –

0

direi che usano Number, in modo da poter utilizzare queste classi con AtomicInteger e BigInteger ecc come bene.

Per quanto posso dire, l'unica differenza "reale" tra il DoubleProperty e IntegerProperty è il metodo setValue(Number v) - si usa v.doubleValue(), l'altro v.intValue().

Non ho un ambiente javafx funzionante qui, quindi non posso testare, se l'utilizzo di IntegerProperty con un Double genererebbe un'eccezione.

fonte

2016-01-08 10:57:43 hinneLinks

 Problemi correlati

  • Nessun problema correlato^_^