Until now you just wrote code to define and create objects. It is time, however, to lean back and consider some important points related to reliability and productivity.
A first point to note is that the
contribution objects created at runtime are all immutable. This means that once an object is created, its attributes cannot be set to different values. Hence, if an object is created and stored in constant
c as follows:
const contribution c = fa_contribution.create ( & identifier = 123 & first_name = "Albert" & last_name = "Newton" & random_number = 5 & date_time = fa_local_date_time.create ( "2011-08-27 16:16:30"~ ) )
then instructions such as the following one are refused by the compiler:
c.first_name = "foo"
This is a direct consequence of the following important immutability rule integrated in Obix:
By default all objects are immutable.
This rule increases the reliability of software because immutable objects are simple and less error-prone. They are thread-safe and can be freely shared in parallel processing applications. They are also less vulnerable to malicious attacks and there are no state transitions to manage.
For further information please consult Chapter 7, Object immutability in the language manual or search the internet for articles about the importance of immutable objects.
Another important and effective Fail fast! rule integrated in Obix is:Void objects are not allowed by default.
Void values (also called
null values in other languages) are one of the most frequent reasons for bugs in applications. Therefore
void values are not allowed by default in Obix. Any violation is detected by the compiler or else immediately at run-time.
void to any attribute of a
contribution object is refused by the compiler. Example:
const contribution c = fa_contribution.create ( & identifier = void & ...
For further explanations please consult Chapter 6, Void values in the language manual.
|It is interesting to note that most programming languages support opposite rules: Objects are mutable by default and void values are allowed by default.|
Other concepts for increased reliability you have encountered so far are:
Unit testing (as seen in the previous chapter)
Implementation hiding enforced by the language through the concept of types and factories. Some languages allow programmers to define a class (factory) that doesn't implement an interface (type), and they allow the type of an object reference to be a class. This is considered bad practice because implementation details are exposed and code depends on them. In Obix you can't do that. You have to define a type and a factory, and the declaration of an object reference can only use a type, not a factory.
Finally it is interesting to note (for Java programmers) that:
You don't need to write
set methods (except in non-standard cases).
You don't need to write and manage
You can define standard creators which take one input argument for each attribute with a single instruction:
creator create kind:in_all end