Por qué no podemos pasar a una propiedad como argumento para desatar Propiedad # () en JavaFX?

votos
0

Vamos a considerar dos métodos de Propertyinterfaz:

Property#unbind() 
Property#unbindBidirectional(Property<T> other) 

Como vemos, cuando queremos eliminar la unión bidireccional podemos pasar a la propiedad para la que queremos eliminar esta unión.

Sin embargo, cuando quitamos unidireccional de unión que no podemos pasar dicha propiedad. ¿Cómo explicarlo?

Publicado el 20/10/2018 a las 10:29
fuente por usuario
En otros idiomas...                            


1 respuestas

votos
1

enlaces unidireccionales

Los métodos implicados en fijaciones son unidireccionales bind, unbindy isBound.

Es importante saber que las consolidaciones unidireccionales son uno-a-uno 1 . Esto se hace para mantener la consistencia. Considere qué pasaría si varios enlaces unidireccionales se permitió al mismo tiempo. Si tenemos:

AB
AC

Lo que debería Acontener? El valor de Bo el valor de C? El contrato del bindrequiere que la Propertyvoluntad siempre contiene el valor de la ObservableValue. A partir de javafx.beans.property:

Todas las propiedades se pueden unir a ObservableValues ​​del mismo tipo, lo que significa que la propiedad contendrá siempre el mismo valor que el ObservableValue unido.

El Propertyno puede mantener este contrato si hay más de una ObservableValuede observar. Por lo tanto, un uno-a-uno 1 relación se cumple.

Como consecuencia de este uno-a-uno 1 relación, no es necesario pasar el ObservableValueal llamar unbind. La única posible ObservableValueque podría ser destinado es la anteriormente dada a través bind.

Vale la pena mencionar que llamar binden una cota ya Propertyimplícitamente desvincular de la anterior ObservableValue. Al menos, así es como funcionan las implementaciones estándar. No pude encontrar la documentación que define este comportamiento así que supongo que una implementación podría lanzar una excepción en su lugar.

1. Técnicamente, es un muchos-a-uno relación. Más de uno Propertyse puede unir a la misma ObservableValue, pero que uno Propertyno se puede unir a más de una ObservableValue. Me voy de uno-a-uno en la respuesta, sin embargo, porque creo que mejor ilustra la diferencia entre fijaciones unidireccionales y bidireccionales.

enlaces bidireccionales

Los métodos implicados en fijaciones son bidireccionales bindBidrectionaly unbindBidirectional.

Para los enlaces bidireccionales, es la relación de muchos a muchos . También son independientes de las consolidaciones unidireccionales. A partir de bindBidirectional:

Crear una vinculación entre esta propiedad y otro bidireccional. encuadernaciones bidireccionales existe independientemente de las consolidaciones unidireccionales. Por lo tanto, es posible añadir unidireccional de unión a una propiedad con la unión bidireccional y viceversa. Sin embargo, esta práctica no se recomienda.

Es posible tener varios enlaces bidireccionales de una propiedad.

Se deja que esta relación muchos-a-muchos para los enlaces bidireccionales, ya que causa cada uno Propertyde espejo uno del otro . Si uno cambia, las otras actualizaciones. A partir de javafx.beans.property:

También es posible definir una unión entre dos propiedades bidireccional, de modo que ambas propiedades siempre contienen el mismo valor. Si una de las propiedades cambia, el otro será actualizado.

Esto significa que el problema de la consistencia que las consolidaciones unidireccionales tienen no es compartida por fijaciones bidireccionales. Considera lo siguiente:

ABC

Si Alos cambios, a continuación, Bse actualizará. Debido a que Bse ha actualizado, Cserá también actualizar. Esto significa que en un momento dado todas las propiedades tienen el mismo valor. Sin ambigüedad.

Como consecuencia de esta relación de muchos a muchos, el objetivo Property se requiere cuando unbinding; el límite Propertytiene que saber lo que Property se necesita para desenlazar partir.

Respondida el 20/10/2018 a las 11:19
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more