A computerized system stores many kinds of information.
A soccer program might work with:
These values do not all behave the same way.
A program can add two goal counts.
It can compare whether two jersey numbers are equal.
It can display a player's name.
It can use a true/false value to choose a path.
The type of a value helps the program understand what kind of information the value represents and what operations make sense for it.
Consider:
7
That could represent a number.
Now consider:
"7"
The quotation marks suggest text containing the character 7.
Those two values may look similar to a person, but a program can treat them differently.
A numeric 7 can naturally participate in arithmetic:
7 + 2 = 9
Text "7" is information made of characters.
The program needs to know which interpretation is intended.
A soccer system might use a whole number for:
jerseyNumber = 7
or:
goals = 3
A measurement may need a value with a fractional part:
heightMeters = 1.82
Both are numeric, but the information is not identical.
A whole-number count and a decimal measurement can require different representations.
The type should fit the information the program actually needs.
A player's name is not a quantity.
It is text:
name = "Jordan"
A team name is also text:
teamName = "Wildcats"
Even when text contains digits, it may still be text.
For example:
uniformCode = "A17"
The value includes a digit, but the program would not normally perform arithmetic on the code.
You have already worked with Boolean values.
For example:
isAvailable = true
or:
hasStarted = false
A Boolean is useful when the information is naturally a yes/no or true/false state.
The field name supplies the meaning.
true by itself is vague.
isAvailable = true is much clearer.
A model should not only identify that information exists.
It should also help communicate what kind of information it is.
Suppose a soccer system needs these values:
name
jerseyNumber
heightMeters
isAvailable
The model can become more precise when it identifies their types.
Conceptually:
name : text
jerseyNumber : whole number
heightMeters : decimal number
isAvailable : true/false
Later, UML class diagrams will express this idea using attribute notation.
C# will also require types when data is declared.
Imagine trying to calculate:
"Jordan" + 5 goals
The operation does not have an obvious numeric meaning.
Now consider:
currentGoals + 1
That makes sense if currentGoals is a numeric value.
Types help both programmers and programming tools identify which operations are appropriate.
They also help expose mismatches when one part of a program expects one kind of information and receives another.
Suppose:
goals = 2
Later:
goals = 3
The value changed.
The kind of information did not.
It is still a whole-number goal count.
Likewise:
isAvailable = true
can later become:
isAvailable = false
The Boolean value changed while the type remained Boolean.
Consider:
jerseyNumber
The name tells you what the information means.
The type tells you what kind of value can represent it.
A useful model needs both.
A field called:
value
with no other context does not tell you much.
A field called:
jerseyNumber
with a whole-number type is much more informative.
Do not choose a type because it is familiar.
Choose it because it matches the information.
Ask:
Those questions are the beginning of data-type selection.
The next activity focuses directly on choosing an appropriate type for simple information.