Properties or fields?


I finished yesterday discussing how you specify data (sometimes referred to as object state) in objects leading into todays discussion.

Fields are just any old object (data) that is held in either class or instance data. In COBOL terms(err, broadly), Working-Storage or Local-Storage. They can be private or public. Now, private fields are all the rage … Your code will and should contain private fields like:

01 If-Person-Male   condition-value private.
01 Person-Sex       string          private.

 

A quick note here, there are a range of built in types in Visual COBOL 2010.  condition-value is a Boolean, with values either true or false, a simple 88 level if you like.  string is the .NET System.String type.  For a full list of built-in types click here.

Using public fields however is a bit problematic because they give other code the right to alter data in your objects. Your object data can then become inconsistent or corrupt, leading to unpredictable behaviour.  Fields, to use the magic OO buzz-word, break encapsulation. For a quick user-friendly definition of encapsulation check out here,  but Wikipedia provides a more complete description.

Properties are a way for you to expose your object data in a controlled way. Properties are essentially, under the covers, a .NET shortcut to two methods or functions: get_propertyname and set_propertyname. So:

01 Person-Id        binary-long              as "Id"             
                    public property with no set.

will generate two methods: get_Id and set_Id that return an integer (binary long) and take as parameter an integer respectively.  The interesting additional point about this statement is the with no set. This means that the class does not expose the set method for the property as public. This property can be viewed by external code, but only the objects internal methods can alter this property’s value. If you make all of a class’s public property’s only have public get methods and go one step further by not allowing the object to change those properties other than at the point of creation, then the object is described as immutable. Immutable objects are a good idea as they always guaranteed to be in a self-consistent state and are inherently thread-safe, i.e. they can be safely accessed by multiple threads after created. Not every class can be immutable but try … It will pay off in the long run!

The neat thing about property’s is that they can make behaviour look like data and transform a view of data to another type.  Let’s look at an example by adding to the Working-Storage:

01 Person-Male      condition-value          as "Male"           
                    public property with no set.

Now if we add lower in the code (The complete code for viewing in context can be found here):

method-id get property Sex.
procedure division returning Return-Value as string.
    
    If  Person-Male
        Set Return-Value to "Male"
    Else
        Set Return-Value to "Female"
    End-If.

end method.

method-id get property Female.
procedure division returning Return-Value as condition-value.
    
    If  Person-Male
        Set Return-Value to false
    Else
        Set Return-Value to true
    End-If.

end method.

We’ve now defined two extra get property’s Sex and Female. Sex returns a string based on the Male (Person-Male) property: “Male” if it is true or “Female” if it is not. We could take it further and return “Boy” or “Girl” if the person was younger than 12 years of age. Neat, eh?! The Female property is effectively the inverse of the Male property as (by and large!) you can’t be both male and female. If we weren’t trying to make our Person class immutable we could provide a set method for Female like:

method-id set property Female.
procedure division using by value Input-Value as condition-value.
    
    If  Input-Value
        Set Person-Male to false
    Else
        Set Person-Male to true
    End-If.

end method.

 

We can thus ensure that the internal state of the Person object is entirely consistent.

A final point about property’s … If you choose to use public property’s instead of public fields, your class will automatically support data binding. We’ll get on to data binding later in this series, but believe me – you want it!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: