Dot Net

Converting Strongly Typed Collections to Generics: Part 2

2008-07-03T02:39:00Z

In Part 1, the idea of converting your strongly typed collections to Generics was introduced. Backward compatibility and existing client support was maintained. However once a level of acceptance has been maintained for the new base class and the reduced amount of code in the collection classes, new development can utilize new constructs in c#3.0 which can reduce the code in your strongly typed collections even more, as well as eliminating the strongly typed collections all together. See the code snippet below which shows the base generic class.

public class BaseGenericCollection<T> : System.Collections.ObjectModel.Collection<T>
{
internal List<T> m_deletedList = null;

    new public void Add(T t)
    {
        if (this.Contains(t))
            throw new System.ArgumentException("Cannot add duplicate entry to collection.");
        base.Add(t);
    }
    public void Delete(T t)
    {
      if (t == null)
      {
throw new ArgumentNullException("T", "BaseGenericCollection: Cannot Delete NULL from collection.");
      }
      if (m_deletedList == null)
      {
          m_deletedList = new List<T>();
      }
      this.m_deletedList.Add(t);
      base.Remove(t);
    }
}

The base class now no longer needs the GenericSorter<T> internal class it had in Part 1. The strongly typed StudentCollection is also no longer needed, but can be kept around for backward compatibility. However the same functionality can still be achieved, along with type safety, using anonymous methods, or even cleaner syntax with lambda expressions. Lambda expressions simplify the syntax of defining at run time, logic that can be invoked in response to an event without needing a dedicated method for the event handler.

Consider the following code which illustrates using lambda expressions to sort a collection that has a new base class.

static void Main(string[] args)
    {
      //Load up a Generic collection of Student objects
      BaseGenericCollection<Student> _students = LoadStudents();

      //Notice that the Students can be ordered within the loop using the OrderBy method from the extension
      //methods from System.Linq within CollectionBase<T>
      //and the syntax can be reduced using the Lamda operator instead of an anonymous method
        foreach (var student in _students.OrderBy(student => student.Major))
        {
          Console.WriteLine("{0,-10} \t{1,-10} \t{2,-10} \t{3,-10:d} \t{4,-10:D} ",
   student.FirstName, student.LastName, student.Major,
   student.EnrollmentDate, student.GraduationDate);
        }

The local student collection instance, _students, is now a BaseGenericCollection<Student> type and still has all the capabilities it had previously but with less code. The base class’ base class System.Collections.ObjectModel.Collection<T> has an extension method in System.Linq for sorting called OrderBy that requires to be passed a delegate, which can be replaced with a lambda expression.

New Constructs

C# 3.0 supports the capability of handling events inline by assigning or delegating a chunk of code directly where an event handler will be referenced, instead of creating a dedicated method to respond to an event. This approach takes advantage of anonymous methods. The syntax can be a little “too busy” or confusing. The syntax can be cleaned up using lambda expressions, which are cleaner, more simply ways of creating anonymous methods.

The MSDN Library defines a lambda expression as “… an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.” The syntax can be broken down as: arguments to be processed => (goes to) statements to be processed. In the example above, the OrderBy method is passed a student instance (to be evaluated once it is referenced via the foreach loop) which is the object to be processed, then the “goes to” operator (=>)and student.Major, ( the value of the student’s major), which is the statement that is to be processed. The OrderBy method actually considers it like an identity function according to the MSDN Library.

To illustrate lambda expression or more so, the statements to be processed consider the following example.

//First define the major we are looking for
Program._majorToFind = "Physics";

//Now we can loop thru the collection that is returned from casting to a List<Student> collection and using the FindAll method, using the Lambda operator
foreach (var student in _students.ToList<Student>().FindAll
    (student => student.Major == Program._majorToFind))
    {
        Console.WriteLine("{0,-10} \t{1,-10} \t{2,-10} \t{3,-10:d} \t{4,-10:D} ", student.FirstName,
        student.LastName, student.Major, student.EnrollmentDate, student.GraduationDate);
    }

//Now we utilize the Find method, to find a specific instance with specific data, using the Lambda operator
Program._lastNameToFind = "Valenti";
Student students = _students.ToList<Student>().Find(student => student.LastName == Program._lastNameToFind);

Notice the foreach, the type that is being retrieved is defined as a var which is an anonymous type that is ultimately returned from the Find and FindAll methods of List<T>. Those methods expect to receive a System.Predicate<T>, which is ultimately a delegate or method pointer. As illustrated above, a method pointer can be replaced by an anonymous method which also can be replaced by a lambda expression. The statements to be processed in the lambda expression are looking for student instances with a student Major property value of “Physics” and only return instances with those values.

The same is true for the Find method of List<T>. It requires a method pointer which can be replaced with a lambda expression that returns the student object with the LastName property equal to Program._lastNameToFind.

Your strongly typed collection code can be further reduced than that illustrated in Part 1, by utilizing new constructs added to the c# language. These new objects and constructs actually make it more readable and understandable once you understand how they are read. All the compiler time type checking is maintained and the compiler infers the correct type for the anonymous types used in the lambda expressions.

In Part 3, the lambda expression will be replaced with Language Integrated Queries (Linq).

Converting Strongly Typed Collections to Generics: Part 1

2008-05-29T01:44:00Z

Many enterprise applications make use of strongly typed collections in their solution. Although they require more development time, the advantages they provide can outweigh the cost of the extra development time. Some of the advantages include compile time and run time type safety, processor time savings from not having to downcast, the time to search and perform type checking, and sorting on specific properties. .Net 1.1 contains base classes that provide all the typical methods and properties needed to build your own strongly typed collection class. But as previously mentioned extra development time is needed to develop a collection class for each business class that can exist in multiple, simultaneous versions at run time. This leads to higher development costs and higher maintenance costs. Business requirements grow over time, and new properties can be added to business classes that require sorting at the application tier, thus needing development time to update the collection class to allow sorting on the new properties. Also some properties can have their exposure increased and thus needing a new “FindBy…” method in the collection.
Much of this development time can be reduced using Generics, a new construct added to c# 2.0. However when environments and projects must adhere to consistent standards, before new technologies make their way into new development cycles, sometimes legacy solutions will be converted to the new technology prior to new functionality using it. Also if it is required to maintain either backward compatibility, or existing client code, removal of the existing strongly typed collections could be prohibited. However reducing its code base and maintaining its existing signature is possible with Generics.

The topic of converting all your strongly typed collection classes will be discussed and broken up into 3 separate parts. When large enterprise applications contain many strongly typed collection classes, converting them to Generics can contain large amounts of risk and could be separated into different steps that reduce risk, and keep a higher level of quality.

Here in Converting Strongly Typed Collections to Generics Part 1, the first step will be only to reduce the amount of code in each of the strongly typed collection classes by using Generics. The basic structure of a non generic strongly typed collection class will be discussed with an example of all the usual parts. Then the strongly typed collection class will have the majority of its code removed as well as changing its base class to use Generics, all the while maintaining backward compatibility.

Strongly Typed Collections

A strongly typed collection class has the typical methods and properties of any collection class but only accepts and processes 1 type. For example, see the code snippet below that illustrates some typical methods. Note this is only a snippet of the class; download the project to see the entire collection class as well as the complete example. The snippet below illustrates the typical properties and methods that a collection class and namely a strongly typed collection class will contain.

public class StudentCollection : BaseCollection
{
    public Student this[int index]
    {   //List handles throwing ArgumentOutOfRangeException
        get {return (Student)List[index];}
        set { List[index] = value; }
    }

    public int Add(Student student)
    {
        if (student == null)
        {
            throw new System.ArgumentNullException("student", "Cannot Add NULL to collection.");
        }
        // Is List a Unique list?
        if (IsUnique && List.Contains(student))
        {
            throw new System.ArgumentException("Cannot add duplicate entry to collection.");
        }
        return List.Add(student);
    }

    public StudentCollection FindByMajor(string major)
    {
        StudentCollection studentCollection = new StudentCollection();
        foreach (Student student in this.List)
        {
            if (student.Major == major)
            {
                studentCollection.Add(student);
            }
        }
        return studentCollection;
    }

Note the indexer only indexes on a Student object, and the Add method only adds a Student type. Also the FindByMajor method is specific to a StudentCollection and searches only for Student objects.
When using the collection, it is pretty straight forward, you can new a Student object, add it to an instance of a StudentCollection, and find a specific Student instances. See the code example below.

Student student1 = new Student(1, "Ben", "Franklin", "Physics");
StudentCollection students = new StudentCollection();
students.Add(student1);
StudentCollection studentsToFind = students.FindByMajor("Physics");

Normally the collection will be filled at a database tier or other method, and the collection will contain more than 1 Student object. For simplicity only a snippet is shown here.

Generics
Now we will look at creating a Generic base class and removing the common code used by all collections.

public class BaseGenericCollection<T> : System.Collections.ObjectModel.Collection<T>
{
internal List<T> m_deletedList = null;

   new public void Add(T t)
   {
        if (this.Contains(t))
           throw new System.ArgumentException("Cannot add duplicate entry to collection.");
        base.Add(t);
   }

The base class will inherit from System.Collections.ObjectModel.Collection<T> and will contain all the typical properties and methods any collection class has, but it will be instantiated with a type and thus will maintain its type safety. Notice there is no “FindBy…” method, because we won’t know what type this class will be instantiated with.

Now let’s look at the Student Collection. Remember, we are only removing the typical parts of strongly typed collection into a reusable base class that maintains type safety. The StudentCollection class will still exist, but will only contain the custom methods and/or properties specific to a StudentCollection class.

public class StudentCollection : BaseGenericCollection<Student>
{
    public StudentCollection FindByMajor(string major)
    {
        StudentCollection studentCollection = new StudentCollection();
        //Create a temporary anonymous collection
        //and use a lambda expression to only select those students with the desired major.
        //The compiler will infer the type and maintain type safety
        var students =
            this.Select((student, index) =>
                    new
                    {
                        index, studentToFind = student.Major == major
                    }
            );

        //Loop thru the anonymous type
        foreach (var student in students)
        {
            if (student.studentToFind)
            {
                studentCollection.Add(this[student.index]);
            }
        }
        return studentCollection;
    }
}

The StudentCollection class inherits from our BaseGenericCollection which is really a Collection<T> of Student objects which provides the type safety that was required in the legacy application.
We can also take advantage of other new constructs in c#3.0, namely anonymous types and lambda expressions. An anonymous type can be used to select a collection of student objects that meet the criteria using lambda expressions. The lambda expression reduces the amount of code compared to an anonymous method.

Upgrading your strongly typed collections to Generics can reduce your code base, and time to maintain the classes. When there are several strongly typed collections and they are used throughout the application, taking small steps in upgrading them will reduce the risk of introducing defects, and keep the quality at a level that is arguably acceptable by all the teams.

Next in Part 2 we will discuss removing all the strongly typed collections and having only 1 collection used throughout your application. The type safety will still be maintained and the “FindBy…” methods will be moved to the tier that instantiates the Generic base class.