Monday, December 4, 2006

Essential .Net Chapter 3: Type Basics

[This was originally posted at]


Chapter 3 of Don Box's book Essential .Net: the CLR explains the basic of types. While this is a common topic. Don has a clear way of explaining things. He does a good job of explaining the concepts of types in a way that transcends individual language syntax. This chapter connects a lot of dots, and makes a lot of sense once you've already been using an OOP language like C#. While most of this I've already seen before in other C# books, Don has a good way of explaining it:

Types - "A CLR type if a named, reusable abstraction." (pg 49) - I constantly have junior devs asking "What is a type?" I've heard several answers, like "A type (or form, or kind) of data", but I think Don's phrasing helps clarify the intent.

Sealed vs. Abstract - He explains how the class modifiers sealed (cannot be inherited) and abstract (must be inherited) are really opposites.

Const vs. Readonly - He discusses the difference between the const (made constant at compile time) and readonly (set in the type initializer at runtime, and then no longer editable). For example, consider this code snippet:

  class TypeDemo
    public TypeDemo()
      c2 = 456;
      c2 = DateTime.Now.Second;

    public const int c1 = 123;
    public readonly int c2;

    private void MyMethod()
      //This would cause a compile error:
      //c2 = 123;

Params - He discusses the params keyword in a method signature, which lets you pass in a variable amount of parameters into a method. The called-method receives these params as an array. Using Ildasm to view the code, one can see that the params keyword generates the System.ParamArrayAttribute.

    public static void DialEm(string message, params string[] numbers)    {      //Do stuff    }    public static void CallFred()    {      DialEm("Hi Fred!", "123", "456", "789");    }

Constructors - He explains about static vs. instance constructors. Looking at the IL, it's interesting to note that the static method has the name ".cctor", and the instance method has the name ".ctor" (only 1 c).

Interfaces - He points out that interfaces can strongly-type the context that an object should be used in. SO if you have objects AmericanPerson, CanadianPerson, and Turnip, you can have the first two objects implement the IPerson interface so that methods (at compile time) can uses those in a "person" context. By having an object implement multiple interfaces, you allow it to clearly be used in multiple contexts.

Overall, this chapter constantly transcends just the C# language and points to what the IL actually looks like. Constantly seeing the IL helps to fill in some gaps and see the significance of certain coding decisions.

Lastly, Don observes about the importance of types that "Developers spend most of their time defining new types in terms of existing types." (75). This is an interesting observation, and something that code generation is actively trying to address. For example, without codegen, a developer will spend a significant amount of time constructing objects that map to their database, like an "Employee" and "Customer" object. However, with codegen, the developer ideally just generates these objects based of of existing schema (such as a database or an xml file).

No comments:

Post a Comment