Prefer Domain-Specific Types to Primitive Types

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (19:30, 10 July 2009) (edit) (undo)
 
(16 intermediate revisions not shown.)
Line 1: Line 1:
-
One of the main features provided by object-oriented languages are abstract data types and strong typing. Still many developers uses the primitive data types offered by the language such as String. Wrapping complex data structures as strings are simple as the object method basically can take any data, but it's also an unsafe style of programming, where the developer avoids delegating appropriate quality control to the compiler.
+
On 23rd September 1999 the $327.6 million Mars Climate Orbiter was lost while entering orbit around Mars due to a software error back on Earth. The error was later called the ''metric mix-up''. The ground station software was working in pounds while the spacecraft expected newtons, leading the ground station to underestimate the power of the spacecraft's thrusters by a factor of 4.45.
-
Ada developers are encouraged to utilize the strong typing offered by the language. The benefit is safer code as can be seen from the example below:
+
This is one of many examples of software failures that could have been prevented if stronger and more domain-specific typing had been applied. It is also an example of the rationale behind many features in the Ada language, one of whose primary design goals was to implement embedded safety-critical software. Ada has strong typing with static checking for both primitive types and user-defined types:
-
subtype Velocity_In_Knot is Float range 0..500.00;
+
subtype Velocity_In_Knots is Float range 0..500.00;
-
subtype Velocity_In_Km is Float range 0..300.00;
+
subtype Distance_In_Nautical_Miles is Float range 0..3000.00;
-
V1: Velocity_In_Knot;
+
Velocity: Velocity_In_Knots;
-
V2: Velocity_In_Km;
+
Distance: Distance_In_Nautical_Miles;
-
Speed: Float;
+
Some_Number: Float;
 +
 +
Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type error.
 +
 
 +
Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is know as <code>class</code>. Using classes such as <code>VelocityInKnots</code> and <code>DistanceInNauticalMiles</code> adds a lot of value with respect to code quality:
-
With these types and variables defined the statement <code>Speed:=V1+V2;</code> will be caught by the compiler as a type error.
+
# The code becomes more readable as it expresses concepts of a domain, not just <code>Float</code> or <code>String</code>.
 +
# The code becomes more testable as the code encapsulates behavior that is easily testable.
 +
# The code facilitates reuse across applications and systems.
-
The same level of strong typing can be achieved by any object-oriented programming language such as Java, C++, and C# by defining the appropriate data type as a class. The Value Object pattern from Eric Evans book [http://www.domaindrivendesign.org/books/index.html#DDD Domain-Driven Design] provide good programming practices for these languages. By defining values for velocity, money, and distance in terms of classes, safe arithmetical operations can be supported combined with many other benefits such as more readable code, fewer lines of code and increased reuse.
+
The approach is equally valid for users of both statically and dynamically typed languages. The only difference is that developers using statically typed languages get some help from the compiler while those embracing dynamically typed languages are more likely to rely on their unit tests. The style of checking may be different, but the motivation and style of expression is not.
-
Therefore, developers should stop to misuse primitive data types for convenience, and start on the journey of exploring the power of strong typing and the Value Object pattern.
+
The moral is to start exploring domain-specific types for the purpose of developing quality software.
By [[Einar Landre]]
By [[Einar Landre]]

Current revision

On 23rd September 1999 the $327.6 million Mars Climate Orbiter was lost while entering orbit around Mars due to a software error back on Earth. The error was later called the metric mix-up. The ground station software was working in pounds while the spacecraft expected newtons, leading the ground station to underestimate the power of the spacecraft's thrusters by a factor of 4.45.

This is one of many examples of software failures that could have been prevented if stronger and more domain-specific typing had been applied. It is also an example of the rationale behind many features in the Ada language, one of whose primary design goals was to implement embedded safety-critical software. Ada has strong typing with static checking for both primitive types and user-defined types:

subtype Velocity_In_Knots is Float range 0..500.00;

subtype Distance_In_Nautical_Miles is Float range 0..3000.00;

Velocity: Velocity_In_Knots;

Distance: Distance_In_Nautical_Miles;

Some_Number: Float;

Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type error.

Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is know as class. Using classes such as VelocityInKnots and DistanceInNauticalMiles adds a lot of value with respect to code quality:

  1. The code becomes more readable as it expresses concepts of a domain, not just Float or String.
  2. The code becomes more testable as the code encapsulates behavior that is easily testable.
  3. The code facilitates reuse across applications and systems.

The approach is equally valid for users of both statically and dynamically typed languages. The only difference is that developers using statically typed languages get some help from the compiler while those embracing dynamically typed languages are more likely to rely on their unit tests. The style of checking may be different, but the motivation and style of expression is not.

The moral is to start exploring domain-specific types for the purpose of developing quality software.

By Einar Landre

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools