There are two ways to define contract programming conditions:

Please refer to the links in the following table for details about how to code the different kinds of conditions:

Contract programming conditions defined in a type are implicitly inherited in every child type

This rule is a logical consequence of the type compatibility rule. Because a child type is always compatible to all its parent types, all contract programming conditions defined in a type must also be enforced in any child type.

For example, if a type's command returns an integer value that is guaranteed to be greater than 10, a child type must also ensure this condition. If it was allowed to return the value 7, for example, type compatibility would be violated.

Contract programming conditions defined in a type can be loosen or strengthened in a child type, as long as type compatibility is preserved.

Please refer to Chapter 18, Feature redefinition for more information.

Contract programming conditions defined in a type are automatically enforced in every factory that implements this type.

There is no need to explicitly (re)check conditions in factories. For example, if a type specifies that a command's input argument of type string must contain at least 10 characters, then the factory can rely on this condition and doesn't need to add code such as if input_value.item_count < 10 then ....

To ensure that an object reference cannot be void at runtime, property voidable should be used, rather than contract programming.

Although contract programming could be used to check for void, using property voidable is easier to use, and allows the compiler to make some optimizations. However, if the check for void depends on circumstances at runtime, then contract programming must be used (e.g. an attribute's voidability depends on a parameter stored in an XML configuration file)

Please refer to the following links for more information:

If the same condition is defined for more than one object reference (attribute, input argument or output argument), then consider defining a new type that contains this condition and use this type for each object reference.

Suppose types meeting and asset both have attribute remark which is a string limited to 1024 characters. The types could be defined as follows:

type meeting 

   // some attributes not shown here

   attribute remark type:string check: i_remark.item_count <= 1024 end

end

type asset 

   // some attributes not shown here

   attribute remark type:string check: i_remark.item_count <= 1024 end

end

However, a much better solution is to define a new type remark as:

type remark

   inherit string
      attribute value and_check: i_value.item_count <= 1024 end
   end

end

	Note
	This code uses type inheritance and feature redefinition. Please refer to Chapter 15, Type inheritance and Chapter 18, Feature redefinition for more information about these techniques.

Now types meeting and asset can both use type remark like this:

type meeting_2

   // some attributes not shown here

   attribute remark type:remark end

end

type asset_2

   // some attributes not shown here

   attribute remark type:remark end

end

Besides the obvious advantage that the code gets easier to write, the design has been improved for the following reasons: