Just some things to add from my side:

Instead you should always implement the IDisposable pattern.

It’s already mentioned … “best way is to implement both”

This will actually not compile unless the object already implements IDisposable, so this is entirely incorrect.

Hmm, actually it will compile as there is a defensive cast (see 2.) within the using statement. If IDisposable is not implemented then the cast results in null and dispose is not called. Therefore “defensive” and fully legal.

The provided example goes against every best practice known to .NET programmer.

* Fail Fast
* Never eat unhandled exceptions
* Never catch exceptions just to rethrow.

Utter garbage, ignore this one

Totally agree with you on this and am not 100% sure why they do it that way but I guess it has to do with components development. Will look that up again as soon as I am home and have access to the book.

>1. Static objects as keys a static object

I guess the big benefit here is type safety and intellisense. I am not sure about your explanation with the CLR and folding strings. Could you explain this in detail. Afaik strings are immutable and therefore each string exists once in the string pool. Static object would also exist only once. So I guess it would be pretty much the same from an performance point of view .. Unless the object is “smaller” than the string object… not sure if I am correct.

>implicit vs explicit cast

There is a bigger difference here that they don’t touch on. Casting via

lol = (foo)bar;

will throw a invalid cast exception if the cast can’t happen. However the same this way:

lol = bar as foo;

Will fail silently and just set lol to null. This means you need to be aware and check for nulls. Additionally, this cast is slower because it catches the invalidcast exception under the hood.

>Destructors Best way is to implement both and channel the implementation to the method which does the cleanup

Garbage collection in .NET is non deterministic, so your destructor is not called when the object goes out of scope, but instead when there is heap pressure. Because of this, you should never free resources in a finalizer (They aren’t officially called destructors either), otherwise your app could hold open resource handles indefinitely.

Instead you should always implement the IDisposable pattern.

>use “Using” defensive This approach will only call Dispose() if the object implements IDisposeable. Good if you dont really know if the object needs to release resources or not and if you want to be ready for future changes. e.g. the server decides to implement IDisposeable.

This will actually not compile unless the object already implements IDisposable, so this is entirely incorrect.

> 1. Always fire events in a try catch block You never know what the event handler method of the client does, so its good to put the firing into a try catch block. You could write your own EventsHelper class [COMP05, 144] for the purpose of firing event within your classes.

The provided example goes against every best practice known to .NET programmer.

* Fail Fast
* Never eat unhandled exceptions
* Never catch exceptions just to rethrow.

Utter garbage, ignore this one.

>1. Static objects as keys a static object is created to act as a key for e.g. collections (because every instance is unique – has its own identity!). The advantage in comparison to the “old school” version (key is a string) is that the key is already available in memory wheras the string needs to be created everytime. If you use this key in a lot of places it could save some time.

This would only make sense if the C# compiler and CLR didn’t automatically fold strings, so that each string literal is only referenced once. This means that if you have a literal “foo” in your code, the CLR will create it once, and reuse the pointer to it under the hood.

This means that this “performance gain” is bogus, and just leaves really shitty code.

>Containment

This should be Composition.