Bound property

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:

package org.wikipedia.en.object.semantics.property.example;
 
import org.wikipedia.en.taxonomies.domicile.Mansion;
 
/**
 * TrustFundBaby has (?) an (impressive) property.
 */
public interface TrustFundBaby {
  /**
   * Property Getter accessor method for Mansion.
   * Note that Mama and Papa may still be around, in
   * which case I don't have a mansion :(
   *
   * This method will first check with Fifi to see if
   * my prespring are still alive.  If yes, it will return null.
   *
   * However, if Fifi (the hot French maid :) says 'zey have passed a way.'
   * this method will then check with my attorney, Larry, and find out
   * if moi remains a beneficiary.  (They promised the 'Mansion', you see ..)
   * If Larry says, 'I regret to inform you blah blah blah', then again, return
   * null.
   *
   * However, if Larry says 'Boy, have I got news for you, Baby!', then we are
   * getting 'hot' indeed, and its time to check with my accountant-bookie, B.,
   * and find out how crimson indeed is the red mark on the ledger (with yours
   * truly's name on it).  If B. intones 'Guess you don't need those braces anymore',
   * then sigh of relief, but regrettably return null.
   *
   * However, if B. tries to interest me in a "sure bet" on just who Diebold will
   * elect as the next president, then I know I have finally come to some property
   * indeed (and may (if so requested) fire off a series of quick emails to interested
   * observers with the message "Property Change, Baby! :))".
   *
   * Naturally, in that case the method will return the 'Mansion', my 'Mansion'.  
   */
  public Mansion getMansion ();
 
  /**
   * Larry will use this method to pass on the property to me.  (see above.) 
   * Its public since its a legal matter, so that makes it a public matter.  However,
   * if it wasn't a legal matter, I would certainly opt for denying write access to
   * my 'Mansion' property and only expose a read-only Property.
   */
  public void setMansion(Mansion theMansion);
}

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:

package org.wikipedia.en.object.semantics.property.example;
 
import org.wikipedia.en.taxonomies.domicile.Mansion;
import org.wikipedia.specification.component.PropertyChangeListner;
 
/**
 * TrustFundBaby has (?) an (impressive) Bound Property.
 */
 
public interface TrustFundBaby {
 
     // .. fragment to augment above definition of TrustFundBaby interface.
 
  /**
   *  I know a few of you out there are interested to know when
   *  (and if) I ever end up with a Mansion.  If you do, well then,
   *  this method is just for you:  simply call once and leave a
   *  self-addressed call-back reference for notifications.  I'll
   *  keep you posted (promise!) on the 'Mansion' situation.
   *
   *  (B. is sure to call this method to make sure he's (one of) the
   *   first to know if I ever get the Mansion!)
   */
 
   public void addMansionChangeListener (PropertyChangeListener <Mansion> theInterestedOne);
 
  /**
   *  A gold digger (and that includes you too, B. ;), unlike the Page Six, has a passing
   *  interest in my Mansion situation and probably wouldn't care to keep hearing about
   *  any further events regarding my Mansion property.  Boo Hoo?  J'e mon F!  Simply
   *  call this method just once and its Hasta La Vista, Baby! ... NOT!
   */
   public void removeMansionChangeListener (PropertyChangeListner<Mansion> noLongerInterested);
}