Yet another rant on generics

I was on IRC engaged in a spirited debate over generics with a friend. In just about every argument I’ve seen, people are excited about the possibility of adding type safety to collections and eliminating the need for ugly casts. My arguments in this case, are, collections are technical objects that have no semantic meaning in any business domain that I’ve worked. Consequently, I’ve always derived type safety from by using the composite pattern. Though I would agree that this type safety is a “side-effect”, I do not agree that it spells a need to add more type safety to Java. I would argue that the “side-effect” is an intended result of good design. In fact, it’s a pattern that I used quite often in Smalltalk; a language that has only an abstract notion of types that is not enforced by the compiler or the runtime environment. Aside from the fact that composition provides type safety in collections, there are many other advantages of using a semantically significant class instead of using a raw collection. The first (and biggest IMHO) is that a semantically significant class separates “what from how”. This separation of “what from how” helps hide our implementation from users. It also allows us to change our implementation. Granted, we could achieve the same thing by using for example the List interface. But, when have you every come across a business that uses the word list in the vernacular in manner in which is carries the same semantic meaning as java.util.List does? Indexing is a technique that relational databases have long supported. For some reason, it is an optimization technique that has mostly been ignored in the OO world. Our indexes are collections. If we see that our users are looking for information that is held in a collection, we could conceivably optimize that query by adding a second collection to our semantically significant class. Lets say we have an HR application that keeps track of their personal (Person). Now lets say that we would like to hold the Person objects in a map that was keyed by employee id (EmployeeId). If we were to decide to use generics, we’d most likely type HashMap and be done with it. It works pretty well, we create one of these and then when someone wants to query the collection then…. ok, now we have a problem. Where does one put the queries? Id like to follow my good design principles of DRY (don’t repeat yourself) and SRP (single responsibility principle). If I expose the raw collection, do I now have to deligate the responsibility of managing it to the client? Next problem how can/do I protect the implementation details of Person? I need to do this otherwise I’ll not be able to alter that class with incurring a “shotgun refactoring” of the entire application. These problem pretty much leave me with two options; one could extend HashMap to include the queries or one could use composition to expose the queries yet hide the collection. In just about every case, I prefer the later solution because the former doesn’t typically satisfy the “is-a” relationship. Yeah, I know, “is-a” isn’t sexy anymore but that doesn’t make it any less important or viable. Though a Personal object may support queries, that statement Personal is a Map is false. That said, we are now left with composition. In addition to the type safety that composition automatically brings to the plate, it gives us DRY and SRP. We can now delegate and contain all query logic to a single entity. More importantly, we are now free to change the “how” as we see fit. Returning to the example, if we find that the people in the HR department search on a first name last name basis on an equal basis with employee id, then we might decide to optimize Personal by adding in another map where Person is keyed on first and last name. This optimization is not easily available to us unless we contain our queries. Again, composition looks better than inheritance as multiple indexed collection looks much less like a map. I’m afraid that the gene is out of the bottle and the resulting syntactic sugar is here with us to stay. That said, we do need to be careful in how we change the language. If we are changing the language to enhance one aspect of development only to encourage or enable a degradation of another, have we really made progress? In this case what is better, a bit more type checking in the language or encouraging better designs? As you can guess, the discussion didn’t do much to change my mind about generics. I must add that Karl (to his credit) did actually present a single case where generics are helpful that did not involve the typical boring collection argument (I’ll post the example when I can dig it out of my IRC log). But, it was only one example and as nice as it was, it wasn’t significant enough to warrant the modification of the language.