Which of the .NET 3.5 namespaces is the most underutilized yet contains some of the classes and methods considered "must-know" for every .NET developer?
+2
A:
Some developers using .NET 3.5 are, unfortunately, still not familiar with:
- System.Collections.Generic. Developers should not be intimidated by generics at all. They are fun, easy, powerful, and there is a lot of important things based on them. They are a basic building block of more and more important things. There is a junior developer at work who is wondering what to learn, and I'm begging her to check out generics. Generic collections are the best, easiest way to get experience with generics.
- System.Xml.Linq. The new "X" objects, (XDocument, XElement, etc.) make XML a lot easier. This provides a lot of power, even if you're not using them for linq. But they are also a great way to start using linq. And folks, linq is not an advanced specialty technique; it will soon be expected that you can use it. But it's not hard! -And if you're in a VB shop, you can leverage this ability with xml literals. (if you're using vb and not xml literals, you're giving up the only substantial advantage vb has over c#.)
Patrick Karcher
2009-12-24 16:56:12
+1 for Collections.Generic - I see people use List<T> all over the place when they'd be better off inheriting from Collection<T> and creating their own wrapper...
flesh
2009-12-24 17:01:01
Yes, that should be an early thing people learn about .net collection. <Use> straight List but <inherit> from Collection. That's actually a great and practical way to start using inheritance.
Patrick Karcher
2009-12-24 17:13:36
A:
Personally, I feel that System.Threading is underused and misunderstood by many developers. Most modern programming really should have some multi-threaded code, but this is often avoided due to the added complexity.
That being said, there are nuggets in common namespaces throughout the framework that are often underutilized, like some of the classes in System.IO (ie: using string concatenation instead of the Path class methods is something I see far too often).
Reed Copsey
2009-12-24 16:56:21
This cuts both ways - you only want developers who actually *understand* threading to start using it, otherwise you're in a world of pain. So underused in this case may actually be a good thing :)
flesh
2009-12-24 17:02:06
Well, I had mentioned it being misunderstood, too. I feel that this is required learning for any professional developer, at this point. Threading really cannot be ignored any more - the development world has changed. If people don't want to deal with learning multithreading, its tough for me to think of them as serious professionals.
Reed Copsey
2009-12-24 17:37:02
I absolutely agree with you, though encouraging a junior dev to explore and use System.Xml.Linq has far less scope for causing serious trouble than encouraging a junior dev to get stuck into System.Threading :)
flesh
2009-12-24 17:49:49
+1
A:
I find that System.Collections.Specialized has some useful and less well known classes:
- OrderedDictionary
- HybridDictionary
- BitVector
System.Diagnostics is another treasure trove with classes like:
- Debug
- Debugger
- Trace
- StackTrace
- Process
- FileVersionInfo
LBushkin
2009-12-24 16:59:56
I believe it's `BitVector32`. There is also a `System.Collections.BitArray`.
João Angelo
2009-12-24 17:39:35
+1
A:
Got to be System.Linq.Expressions for me. The power of expression trees is overlooked by a lot of developers..
flesh
2009-12-24 17:05:09
+1
A:
A comment to the top answer says "I see people use List all over the place when they'd be better off inheriting from Collection and creating their own wrapper" (by "flesh"). Can someone dwell on this some more? Why should I not prefer using List?
Thanks.
Samik R.
2009-12-24 17:27:08
List<t> is great to use when you need a simple collection. Keep using it; I will! It's members are mostly sealed though, and inheriting is is useless. Collection<t> is designed to be inherited from. You can override all the key things like the Add method. For example you can make a Settings collection that inherits from Collection<string>, and you override .Add to write to write the new value an xml file. Or whatever. You SHOULD often use plain old List<t> though; simple and easy.
Patrick Karcher
2009-12-24 17:35:26
If you're writing an API that you ship, you should never expose List<T> because callers can change the contents of the list behind your back. That's one reason to be careful of List<T>. As for inheriting from Collection<T>, if you create a derived version you're then free to modify as required at a later date. Even better, inherit from ICollection or IList<T> and then delegate storage to a private Collection member. If you do this you've got maximum scope to alter the internal representation of your class without affecting the public interface at a later date.
flesh
2009-12-24 17:40:40
Makes sense - thanks for the comments. Is for never exposing List<T>, I generally expose an IEnumerable<T> from the List, so that the contents can't be changed.
Samik R.
2009-12-25 21:41:50
I have a followup comment on the answer I received above. It is recommended that one do not expose a List<T> object to external users of an assembly, rather expose an IEnumerable<T> or one of its cousins. But it is lot easier to use a List object inside the assembly, because you get the array syntax, and all other List methods. So, I typically have a internal property exposing a List to be used inside the assembly. Is this approach reasonable?
Samik R.
2009-12-31 05:23:28