|
Programming .NET Components, Second Edition
Buy it at Amazon |
|||||||||
|
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.