Programming .NET Components, Second Edition  
Buy it at Amazon
Author Juval Löwy
Publisher O'Reilly Press
Length 644 pages
vbRad Rating: 4 fingers up. (4 out of 5)
Reviewed by Robert Gelb

In all years, I've been reading technical books, I don't think I have ever disagreed with an author more stringently than I did with Juwal Lowy. Don't get me wrong: his technical expertise is impecable. The appearances on the .NET Rocks show and the book reviews at Amazon.com are a testament to that. The book is solid from start to finish.

As often happens, there is a myriad of ways to solve a programming problem. Our previous experiences color the approaches we take to solving future problem. I don't know what Mr. Lowy does day to day, what problems he encounters, etc… Anyway, the problem I have with the author is that he urges usage of interfaces for pretty much everything. Which is, in my opinion, wrong. I am going to take a wild guess and suggest that author has spent a significant time in years past coding COM in C++, which lives and breathes "interfaces". He has now brought this COM ideology over to .NET land.

I favor abstract and virtual methods in the base class over interfaces. So what's wrong with the interfaces? Let's first see what is supposedly right with the interfaces. The key argument is that it allows separation of the interface from implementation. This is generally a good thing. But an abstract class gives exactly the same advantage. Plus more. Let's look at a specific example. You define an interface for a business entity, then have 10 implementations in actual classes. Now midway through the project someone comes along and changes the requirements a bit. You find that you need to add another method to the interface. This means that you now have to have 10 implementation of this method, even if all of 9 out of 10 are going to be exactly the same. Compare this to a virtual method: you implement the default functionality for the new method in the base class. The classes that have different functionality can implement away all they want. What ends up happening in many projects is that you'll have an interface, then a base class that implements the functionality, then business objects that inherit from the base class. I ask you, is that not idiocy?

So the problem is just having to write (or copy/paste) more code for not a lot of benefit. Anyway, there are more problems with "interfaces everywhere" approach, but I'll leave it for another day. Admittedly, interfaces are urged on in only 2 chapters. The rest is just technical goodness. Pretty much anything you wanted to know with regards to components is there - from building simple objects to complex 3rd party controls. Lowy's chapters on asynchronous programming and multithreading are the definitive works on these subjects (for me at least). While other others describe simple situation, here the author manages to hit the nail on the head and show examples that are actually useful in the real world.

So bottom line, other than the interface religion, an all around great technical book.





Want more reviews and sample chapters? Click here.