Bound property
Encyclopedia
A bound property of an object (such as a widget
) is a property
which transmits notification of any changes to an adapter
or event handler.
A simple (and typical) example is the text property of a textbox control. Changes made by an end user can be monitored, and perhaps corrected by a verification routine.
There is still a fair amount of semantic ambiguity in regards to fundamental concepts in object and component orientation, so when discussing the concept of properties (bound or not) we must be clear whether the definition is a general one, or, a specific notion unique to a given language or methodology. (For example, it is somewhat incorrect to omit JavaBean when elaborating the notions of 'bound' or 'property' as specified by the Java platform.)
In general, we speak of object properties in context of component orientation, or libraries of reusable objects, since the specification of an objects properties and object property access methods is fundamentally concerned with addressing contractual specification related to the 'uniform' and 'standard' use and interaction semantics of components.
An object's property, in contrast to its member fields, is a conceptual construct which does not necessarily have (or require) a corresponding data-type member element in the object itself (though it certainly can be internally represented and supported by one or more fields, if required). Also note that an object (clearly) can expose a member field as a property (and JavaBeans Properties, in particular, strictly define the standard exposure of fields as properties).
In general, the above distinction between an object's fields (i.e. its data-type members) and an object's properties is the reason for the fact that fields are specified through data-type declarations, whereas properties are fundamentally specified through the definition of read and write access-semantics. This is an important distinction, and can be encapsulated by the maxim that object fields address internal structural concerns, and properties address use and access semantics concerns.
When we speak of access semantics, in context of properties, what is meant is simply that (unlike a field) the read-write operations on an object's property are managed and observed. For example, consider the following (Java) code snippet which illustrates the key points discussed:
Please note the use of 'interface' in the above (Java) code. An interface in Java can not have member fields, and defining (JavaBean style) property accessor methods (to define a property) on an interface is excellent for clarifying the distinction between fields and properties. An implementation of the above interface is not required have a 'Mansion' field in its class definition.
Thus we can say that 'A property is a virtual data element of an object and the access to the property is managed by getter/read and setter/write methods'.
Given that, we can now discuss what is a Bound Property.
A bound property of an object (such as a widget
) is one which has been bound to a semantic context and changes in its state may potentially affect the wider scope (beyond the owning object itself) and thus beyond simply managing the access to the property, we also need to provide means of updating the wider context of the changes in the property.
For example, in GUI
frameworks which employ the MVC pattern, there is an intrinsic and explicit set of objects, (the model, the view, and the controller,) that together support the abstraction of a 'visual user interface component': changes made in the model (typically through another process) must be reflected in the GUI (by the view); and changes made by user through the GUI (thus the 'View') need to be reflected in the model; and the interaction is managed by the controller (which is typically the extension point of the GUI framework). Here, the various properties of the model (typically the value of the data element backing the GUI representation) are of interest to other objects in the 'binding context' of the model's properties: the model is the 'bound property' of the GUI widget and the binding context is the widget itself, and the interested observer is the controller. By exposing a standard bound property interface, the model allows for the controller to register interest in the model's value property.
Following the code fragment illustrating Property, we can now augment the same interface to demonstrate the notion of Bound Property:
Widget (computing)
In computer programming, a widget is an element of a graphical user interface that displays an information arrangement changeable by the user, such as a window or a text box. The defining characteristic of a widget is to provide a single interaction point for the direct manipulation of a given...
) is a property
Property (programming)
A property, in some object-oriented programming languages, is a special sort of class member, intermediate between a field and a method. Properties are read and written like fields, but property reads and writes are translated to get and set method calls...
which transmits notification of any changes to an adapter
Adapter
An adapter or adaptor is a person that adapts or a device that converts attributes of one device or system to those of an otherwise incompatible device or system.Some adapters may only affect physical attributes:...
or event handler.
A simple (and typical) example is the text property of a textbox control. Changes made by an end user can be monitored, and perhaps corrected by a verification routine.
There is still a fair amount of semantic ambiguity in regards to fundamental concepts in object and component orientation, so when discussing the concept of properties (bound or not) we must be clear whether the definition is a general one, or, a specific notion unique to a given language or methodology. (For example, it is somewhat incorrect to omit JavaBean when elaborating the notions of 'bound' or 'property' as specified by the Java platform.)
In general, we speak of object properties in context of component orientation, or libraries of reusable objects, since the specification of an objects properties and object property access methods is fundamentally concerned with addressing contractual specification related to the 'uniform' and 'standard' use and interaction semantics of components.
An object's property, in contrast to its member fields, is a conceptual construct which does not necessarily have (or require) a corresponding data-type member element in the object itself (though it certainly can be internally represented and supported by one or more fields, if required). Also note that an object (clearly) can expose a member field as a property (and JavaBeans Properties, in particular, strictly define the standard exposure of fields as properties).
In general, the above distinction between an object's fields (i.e. its data-type members) and an object's properties is the reason for the fact that fields are specified through data-type declarations, whereas properties are fundamentally specified through the definition of read and write access-semantics. This is an important distinction, and can be encapsulated by the maxim that object fields address internal structural concerns, and properties address use and access semantics concerns.
When we speak of access semantics, in context of properties, what is meant is simply that (unlike a field) the read-write operations on an object's property are managed and observed. For example, consider the following (Java) code snippet which illustrates the key points discussed:
Please note the use of 'interface' in the above (Java) code. An interface in Java can not have member fields, and defining (JavaBean style) property accessor methods (to define a property) on an interface is excellent for clarifying the distinction between fields and properties. An implementation of the above interface is not required have a 'Mansion' field in its class definition.
Thus we can say that 'A property is a virtual data element of an object and the access to the property is managed by getter/read and setter/write methods'.
Given that, we can now discuss what is a Bound Property.
A bound property of an object (such as a widget
Widget (computing)
In computer programming, a widget is an element of a graphical user interface that displays an information arrangement changeable by the user, such as a window or a text box. The defining characteristic of a widget is to provide a single interaction point for the direct manipulation of a given...
) is one which has been bound to a semantic context and changes in its state may potentially affect the wider scope (beyond the owning object itself) and thus beyond simply managing the access to the property, we also need to provide means of updating the wider context of the changes in the property.
For example, in GUI
Gui
Gui or guee is a generic term to refer to grilled dishes in Korean cuisine. These most commonly have meat or fish as their primary ingredient, but may in some cases also comprise grilled vegetables or other vegetarian ingredients. The term derives from the verb, "gupda" in Korean, which literally...
frameworks which employ the MVC pattern, there is an intrinsic and explicit set of objects, (the model, the view, and the controller,) that together support the abstraction of a 'visual user interface component': changes made in the model (typically through another process) must be reflected in the GUI (by the view); and changes made by user through the GUI (thus the 'View') need to be reflected in the model; and the interaction is managed by the controller (which is typically the extension point of the GUI framework). Here, the various properties of the model (typically the value of the data element backing the GUI representation) are of interest to other objects in the 'binding context' of the model's properties: the model is the 'bound property' of the GUI widget and the binding context is the widget itself, and the interested observer is the controller. By exposing a standard bound property interface, the model allows for the controller to register interest in the model's value property.
Following the code fragment illustrating Property, we can now augment the same interface to demonstrate the notion of Bound Property: