When to use generics and type checking?

Question

Assume A through Z to be 26 classes I defined. In the following example:

  private List<A> _listA;
  private List<B> _listB;
  // private List<C>, and so on, through...
  private List<Z> _listZ;

  private void setLabelA()
  {
      LabelA.Text = _listA.Count;
  }

  // private void setLabelB() exists
  // and so does setLabelC()
  // and so on, all the way through to...

  private void setLabelZ()
  {
      LabelA.Text = _listZ.Count;
  }

It seems to me that there is no way to shorten this other than the following:

  private void setLabel<genericType>(List<genericType> list)
  {
      if(list is List<A>)      LabelA.Text = _listA.Count;
      else if(list is List<B>) LabelB.Text = _listB.Count;
      else if(list is List<C>) LabelC.Text = _listC.Count;
      //  and so on...
      else if(list is List<Z>) LabelZ.Text = _listZ.Count;
  }

Overloading the function name doesn't reduce the number of lines of code:

  private void setLabel(List<A> list)
  {
      LabelA.Text = _listA.Count;
  }

  private void setLabel(List<B> list)
  {
      LabelB.Text = _listB.Count;
  }

I prefer to use the is operator to determine which Label to set, because it preserves space (in this scenario, 50 lines of meaningless brackets and 25 lines of slightly-different function names). However, a Stack Overflow user recommended that I not use generics, and instead use separate functions, one for each Label. Although this solution will work, I prefer to not do so.

Is there any benefit towards NOT using the is operator, and towards explicitly typing my functions?

Answer 1

I will NOT comment about whether it is a good practice or not to do what you are doing :).

If the absence of a label for a given list is NOT the end of the world for you and if you rely on some naming conventions for your label fields so that all labels are named for example "LabelX" where X is your type that will be used for generic lists, you can do that:

using System;
using System.Collections;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Text;
using System.Threading.Tasks;

namespace Labels
{
class Program
{
    static void Main(string[] args)
    {
        Container c = new Container();
        c.ApplyLabels();
    }
}

public class A
{
}

public class B
{
}

public class C
{
}
public class Container
{
    private Label LabelA = new Label ();
    private Label LabelB = new Label ();
    private Label LabelC = new Label ();

    private List<A> _listA = new List<A> ();
    private List<B> _listB = new List<B> ();
    private List<C> _listC = new List<C> ();

    public void ApplyLabels ()
    {
        var allFields = this.GetType().GetFields(BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic);

        Dictionary<Type, FieldInfo> listFields = new Dictionary<Type, FieldInfo>();
        Dictionary<Type, FieldInfo> labelMappings = new Dictionary<Type, FieldInfo>();
        Dictionary<string, Type> namespacesForListGenericTypes = new Dictionary<string, Type>();

        List<FieldInfo> possibleLabelFields = new List<FieldInfo>();
        foreach (var field in allFields)
        {
            if (field.FieldType.IsGenericType)
            {
                var genericTypeDef = field.FieldType.GetGenericTypeDefinition();

                if (genericTypeDef == typeof (List<>))
                {
                    var genericArgument = field.FieldType.GetGenericArguments()[0];
                    listFields.Add(genericArgument, field); // remember list fields and for each list what generic type it has!

                    namespacesForListGenericTypes[genericArgument.Name] = genericArgument;
                }
            }
            else if (typeof (Label).IsAssignableFrom (field.FieldType))
            {
                possibleLabelFields.Add(field);
            }
        }

        foreach (var possible in possibleLabelFields)
        {
            if (possible.Name.Length < 6) continue;

            var typeName = possible.Name.Substring(5);

            Type genericListType;
            if (namespacesForListGenericTypes.TryGetValue (typeName, out genericListType))
            {
                labelMappings[genericListType] = possible;
            }
        }

        foreach (var list in listFields)
        {
            FieldInfo destination;

            if (false == labelMappings.TryGetValue (list.Key, out destination))
            {
                continue;
            }

            var destinationLabel = destination.GetValue(this) as Label;
            if (destinationLabel == null) continue;

            var listValue = list.Value.GetValue(this) as IList;
            var cnt = listValue == null ? 0 : listValue.Count;

            destinationLabel.Text = cnt.ToString();
        }
    }
}

public class Label
{
    public string Text { get; set; }
}
}

Answer 2

Why not just make your own classes which derive their own fields automatically?

private class ListWithText : List<T>
{
    int Text {
        get { return this.Count; }
    }
}

ListWithText<A> LabelA = new ListWithText<A>();
Console.WriteLine(LabelA.Text);

Answer 3

The benefit is that your type checking is static, rather than dynamic. If someone passes in a List<SomeRandomeClassYouDontSupport> to the first method, then the code will compile and just not work properly at runtime. It'll either do nothing, throw an exception, or whatever you code it to do, but the point is that the caller won't be able to see that they did something wrong until they run the code.

When you have multiple overloads then the validation is done at compile time. If an unsupported type is provided then the code won't even compile rather than compiling and not working.

It's also an important semantic difference. Generics are there to say, "This method will work regardless of what the type is". When creating a list there are no right and wrong type arguments to provide. You can create a list of any type that you want. That's an appropriate use of generics, because lists are a conceptually generic data structure. Having several overloads is a way of saying, "This finite list of types is supported." You're in the latter case, so that makes that behavior clearer to the caller, so they'll understand what the method needs to do just by looking at its signature.

Having said all of that, it looks like this isn't even a situation where you should be doing either. If you really wanted to have a method accepting one of a finite number of types known at compile time as a parameter, overloads are the right way to do it, but in your case, you shouldn't be doing any of this at all. You should be binding these UI compontents to a view as mentioned in this comment.