| | 157 | * '''FinalProperty<T>''': |
| | 158 | This Property is somewhat analogical to the '''final''' fields in Java. You can set the value of a FinalProperty only once, though not it's not mandatory to do it in the constructor of the ProObject.[[BR]] |
| | 159 | Such Properties are intended to be used in cases where some user action leads to set the value of a given Property exactly once. This is different than ''const'' AutoProperties as described below. |
| | 160 | * '''AutoProperty<T>''': |
| | 161 | This Property is one of the most commonly used and convenient Properties the ProLib offers. |
| | 162 | |
| | 163 | Basically this is a Property which has a value which is computed directly from the values of some other Properties. In a way, the developer sets the logic of the computation of the AutoProperty's value in a declarative manner and the actual computation of the value is done automatically. Even more, the when some of the Properties on which the AutoProperty depends change their value, the AutoProperty automatically recomputes its value which is very convenient. This saves the developer the hassle of manually implementing some Observer like functionality in all objects a certain Java field X would logically depend and then manually notifying X when they've changed so X can then be manually forced to recompute. |
| | 164 | |
| | 165 | So, like inside the Rectangle example, the area() AutoProperty is implemented like this: |
| | 166 | {{{ |
| | 167 | Prop<Integer> area() { |
| | 168 | class area extends AutoProperty<Integer> { |
| | 169 | @Override |
| | 170 | protected Integer compute() { |
| | 171 | Integer res = width().get() * height().get(); |
| | 172 | return res; |
| | 173 | } |
| | 174 | } |
| | 175 | } |
| | 176 | |
| | 177 | return getBean().makeProp(area.class); |
| | 178 | } |
| | 179 | }}} |
| | 180 | In order to create an AutoProperty, by convention you declare a method structure like the structure of the area() method which declares a local class which extends the AutoProperty class. The type argument of the local class should be identical to the type argument of the Prop which the area() method returns - after all an AutoProperty is a Property which computes a given value following some logic and that value has a type which in our case is Integer.[[BR]] |
| | 181 | So you override the compute() method to provide the AutoProperty's value computation logic inside. You can provide an arbitrary complex logic inside. In this example whenever the width() and height() Properties change their value, the AutoProperty is smart enough to call the compute() method again and update its value.[[BR]] |
| | 182 | '''Something very important:''' compute() will be recomputed only in the cases when some of the '''Properties''' used inside it change their value!! If compute() depends on some normal Java field, there's no way for the ProLib to know when this field has changed its value and then notify the AutoProperty to change its value!! '''There's no magic here!!''' Expecting the ProLib to detect that means hooking to JVM's system events and maybe bytecode instrumentation which obviously we don't want to use (: |
| | 183 | |
| | 184 | |
