Real World Use of Generics (and similar)

[RonNYC]

I've used C# for a long time and in that long time I have never encountered a use for Generics or code which used Generics. When I was the tech lead I advocated for code which was as simple as possible and readable. So when errors occurred it was easy to find the source and correct it.

I think Generics and Anonymous methods are interesting. I just haven't seen a use.

RON

 

[Skydiver]

So did you and your teams code end up having a lot of casting? Or just end up doing the typical "We're working as IT in a non-software development company, so we'll just copy and paste code, then tweak the code"?

Basically how did you solve the problem of needing as list of cars, and then a list of drivers? Did you just use the .NET Framework 1.1 ArrayList and cast everything coming out of the list? Or did you implement ListOfCars and then copy and paste over into a new file, replace the string "Car" with the string "Driver" to implement ListOfDrivers?

 

[RonNYC]

I'm aware of how one would use these features, I've just never seen them in actual use.

 

[Skydiver]

You didn't answer the casting question from post #2.

I picked list because it would have been the most likely thing people would have run into. So your shop never had to deal with domain specific objects and those objects needed to be kept in some kind of data structure beyond an array? Did your shop just have to deal with DataTable and DataSet and arrays only?

Did you just use WinForms controls to act as data structures and just cast objects when getting thing out of them? (e.g. Use a TreeView to hold tree like structures; use a ListBox to hold lists of items.)

How did your shop deal with mapping one type to another type? Hard coded switch statements and casting types with the .NET Framework 1.1 Dictionary?

If you were dealing with WinForms, did you ever had to implement a custom control with custom events? Did those events ever have to derive from the basic EventArgs? Since you say you never had to use generics, that would then mean that you had to explicitly declare event handler delegates for each of those custom events instead of just using EventHandler<T>.

Perhaps it may help if you tell us a bit about the problem space that you and your team used to tackle. Perhaps it may explain why you didn't really run into them or see a need for generics.

For example, my father used to use computers a lot and did some custom programming, but all he really needed was matrices of floating point numbers. Just implement variable sized matrices with matrix operations for floating point numbers and he was happy. Any support methods for scanning through the matrices to select particular rows, columns just devolved into returning an 1xN or Nx1 matrix. For his needs, he didn't really need any generics.

 

[jmcilhinney]

Apart from the fact that you would use List<T> every time you want a dynamic array, i.e. a list that can grow and shrink dynamically, the most obvious use for generics that stands out for me is creating a service layer. We have DTOs for each entity in our EF model and we have a base service interface:

public partial interface IServiceBase<in TDto> where TDto : class

and base service class:

public partial class ServiceBase<TDto>: IServiceBase<TDto> where TDto : class

and then a specific service interface:

public partial interface IAbilityLevelService : IServiceBase<AbilityLevelDto>

and specific service class:

public partial class AbilityLevelService : ServiceBase<AbilityLevelDto>, IAbilityLevelService

for each DTO type. Each service creates an EF context and queries it for the appropriate entity type, then maps those entities to the appropriate DTO and returns those. Common methods are implemented in the base class but, thanks to generics, they are still able to operate on the specific DTO type for that service.