You can find dozens of examples of articles that say something like this:
"The .NET Framework supports strongly-typed resources. Strongly-typed resource support is a compile-time feature ..."
It can get worse! A book by an MIT professor written specifically about software types defines it as, "a tractable syntactic framework for classifying phrases according to the kinds of values they compute". Chew on that for a while!
Most articles fail to actually explain what they mean by "strongly-typed" or "type safety". That's what this Quick Tip is all about.
The best examples of data processing terms always seem to come from the real world. Type is not an exception. When thinking about type, take any collection of objects that "sort of" resemble each other. Dogs, cheeses, cars ... whatever. In all of these things, you can ask the question, "What type of {dog, cheese, car} is it?" And the answer can save you a lot of trouble.
Your 90 year old maiden aunt might need a dog to keep her company. If you just get any "type" of dog from the local Humane Society, your maiden aunt may get an Irish Wolfhound for companionship. So it is with programming. There are built in requirements with most code. If you get a value from another object that your code plugs into a calculation, that value better not be "two" - it better be the number "2" instead. Type safety is the concept that if your code needs a specific type - like a number instead of a string - then it will always get that type. This code illustrates the general problem:
Dim Two As Object
Two = 2
Dim TwoPlusTwo As Integer
' This works
TwoPlusTwo = Two + Two
' This generates a runtime error
' But it DOES NOT create a compile error
Two = "Two"
TwoPlusTwo = Two + Two
Those of you who remember VB6 will remember the Variant type. This is the exact opposite of strong typing. A Variant could be any type at runtime and the idea at the time was that it would be easier not to force programmers to think about data types while they were writing code. The compiler was supposed to take care of those messy details. The decade long experience with Variants in VB6 is one of the reasons why programmers are so firm in their conviction that strong typing is essential today.
One of the advantages of using strongly typed data in a VB.NET development environment is the ability of Visual Studio to help you out with Intellisense and compiler type checking. Intellisense helps you by letting you browse to find the type you're looking for.
For example, if I define a class named Contact ...
Public Class Contact
Public Property LastName As String
Public Property FirstName As String
Public Property PhoneNum As String
Public Property Email As String
End Class
... then Intellisense will help me browse for variable names when I need the object later:
--------
Click Here to display the illustration
--------
If Option Strict is on, it will also prevent a data typing error:
--------
Click Here to display the illustration
--------
If you do a bingle search for information about strongly typed variables, you'll get a lot of hits about "Table Adapters" and databases. Although a database is "strongly typed" because the columns are a specific type, they're not the same types that are used by .NET. Not even Microsoft's SQL Server uses the same .NET types and the other's certainly don't. Creating a "type safe" version of a database is one of the most common problems in strong typing.
The solution is called a provider. In .NET, this technology is called ADO.NET. Part of it is a software layer that is customized to access a particular data store (such as SQL Server or Oracle) and provide the data through a standard interface to your code using .NET types. This is roughly the same solution that was used by OLE DB, except that technology used standard OLE and Windows types rather than .NET types. To make the conversion from OLE DB to .NET easier, a .NET provider is available that interfaces with the OLE DB provider (OleDbDataAdapter). That makes the data go through a double interface so the SqlDataAdapter is faster. The end result is the same, however: a version of the data that is guaranteed to be type safe.