Strongly typed collection is evil, general collection with casting is ugly, generics ends both
vikas has a nice post: Generics – The Code Killer
http://vikasnetdev.blogspot.com/2006/06/generics-code-killer.html
The following is my comment (double post to here)
"Performance" and "type safety" – to be frank, I do not really care either :-) -- the "performance" can never be the hotspot in a database applications; the "type safety" is also not a real problem – who will put a chicken in a fox cage anyway :-) – the really thing is that it removes the ugliness. Whenever I have an argument on whether we use typed collection or casting, I always say casting, but I am always embarrassed by the ugliness.
You are totally right, it comes from classic VB; and the casting is from pre1.5 (“classic”) java. Generics puts the end of both.
I also want to add that it is not just an issue of saving number of classes. It is also an OO concept thing. The reason we say that strongly typed collection is evil (i.e. totally wrong) and casting is just ugly (i.e., bad, but OK), is that strongly typed collection uses an OO model that is obsolete for quite a while (mid-80). Through the experiments in C++ and Java from mid-80 to late-90 of last century, we know that “top level collections” is a bad idea --it should be discarded to a corner (you use it as a last resort). Classic VB was never a real OO; therefore, it had very limited OO experiment community; as a result, it kept the obsolete OO concept, and passed it to .net community.
In "modern" OO model, there is no top level collections, only classes, and 1-m, m-1, m-m class relationships.
posted by survic at
12:54 AM
2 Comments:
Survic,
Thanks for previous post, it was really informative.
I really liked the comment
"Performance and type safety – to be frank, I do not really care either :-) -- the "performance" can never be the hotspot in a database applications"
I have seen people introducing Web Services and dataset as transport mechanism in their application architecture when none required. Then they advice other people not to use reflection because of 1 or 2 milli-second overhead . It does not matter to them that by properly using reflection, one can reduce hundreds of lines of code.
So much for performance design.
I revisited my post. I totally agree Vikas's comment on reflection. The real issue of reflection is its "type safety" (i.e., disabling compiler checking). So, as long as the usage is relatively centralized; it is fine. If we use emit, then, it is even better. I know, all those sounds like perl/javascript talking :-)
I want to add something to the "modern" OO model; because it begs the quesiton: 1-m, m-1, m-m requires collections. Answer: yes, but it only requires general collections. The key thing is that we do not need to put logic in collections. We put it in classes that contain them. You may say that, then, you take away one place to put logic, one powerful tool in the tool box – for example, (a) how about there is some common logic that are shared at the collection level; without strongly typed collection, you have to replicate the logic in the containing class; (b) no mention that sometimes a top level collection is enough, you do not need a class that contains the collection. My response: in theory, you need them; in practice, you do not. Either (a) or (b) will soon turn out to be that it is a temporary situation: (a) the common logic is a fake anyway, you need the “replication” anyway; (b) you need to add some data to the top level collection and turn it into a class containing a collection anyway.
I know, it requires a leap of faith. Let’s put away C++ -- since it is so far way from VB and C#, let’s just talk about Java, the unfriendly sibling. In the life time of Java (now eleven years), nobody uses typed collection, and the domain model in java is not obviously twisted. So, just to make our life easier, let’s stop using top-level collection.
Although generics will eventually put an end of “top level collection”; without explicitly knowing what is going on, it will take much longer; because they are at different levels: one is a language feature; another is an OO concept.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home