Product Description

Brilliantly compiled by author Juval Lowy, "Programming .NET Components, Second Edition" is the consummate introduction to the Microsoft .NET Framework - the technology of choice for building components on Windows platforms. From its many lessons, tips, and guidelines, readers will learn how to use the .NET Framework to program reusable, maintainable, and robust components. Following in the footsteps of its best-selling predecessor, "Programming .NET Components, Second Edition" has been updated to cover .NET 2.0. It remains one of the few practical books available on this topic. This invaluable resource is targeted at anyone who develops complex or enterprise-level applications with the .NET platform - an ever-widening market. In fact, nearly two million Microsoft developers worldwide now work on such systems. "Programming .NET Components, Second Edition" begins with a look at the fundamentals of component-oriented programming and then progresses from there. It takes the time to carefully examine how components can simplify and add flexibility to complex applications by allowing users to extend their capabilities. Next, the book introduces a variety of .NET essentials, as well as .N ET development techniques. Within this discussion on component development, a separate chapter is devoted to each critical development feature, including asynchronous calls, serialization, remoting, security, and more. All the while, hazardous programming pitfalls are pointed out, saving the reader from experiencing them the hard way. A .NET expert and noted authority on component-oriented programming, Lowy uses his unique access to Microsoft technical teams to the best possible advantage, conveying detailed, insider information in easy-to-grasp, activity-filled language. This hands-on approach is designed to allow individuals to learn by doing rather than just reading. Indeed, after digesting "Programming .NET Components, Second Edition", readers should be able to start developing .NET components immediately.

Product Details

• Amazon Sales Rank: #306503 in Books
• Published on: 2005-07-27
• Original language: English
• Number of items: 1
• Binding: Paperback
• 624 pages

From the Publisher
Programming .NET Components, Second Edition is the consummate introduction to the Microsoft .NET Framework--the technology of choice for building components on Windows platforms. From its many lessons, tips, and guidelines, readers will learn how to use the .NET Framework to program reusable, maintainable, and robust components. Following in the footsteps of its best-selling predecessor, Programming .NET Components, Second Edition has been updated to cover .NET 2.0.

About the Author
Juval Lowy is a seasoned software architect and the principal of IDesign, a consulting and training company focused on .NET design and .NET migration. A Microsoft Regional Director for the Silicon Valley, he works with Microsoft on helping the industry adopt .NET. Juval participates in the Microsoft internal design reviews for future versions of .NET. He also helped found Bay.NET - the California Bay Area .NET User Group and he chairs its program committee. Juval is a frequent speaker at the major international software development conferences, where he talks about .NET, component-oriented design, and development process. Juval published numerous articles, regarding almost every aspect of .NET development. He is a contributing editor to the Visual Studio Magazine and a regular columnist to the CoDe Magazine. He has also written for MSDN magazine. Microsoft recognized Juval as a Software Legend as one of the world top .NET experts and industry leaders. Contact him at www.idesign.net

Excerpted from Programming .NET Components by Juval Lowy. Copyright © 2005. Reprinted by permission. All rights reserved.
Chapter 3 Interface-Based Programming

As explained in Chapter 1, separation of interface from implementation is a core principle of component-oriented programming. When you separate interface from implementation, the client is coded against an abstraction of a service (the interface), not a particular implementation of it (the object). As a result, changing an implementation detail on the server side (or even switching to a different service provider altogether) doesn’t affect the client. This chapter starts by presenting .NET interfaces and describing what options are available to .NET developers when it comes to enforcing the separation of interface from implementation. It then addresses a set of practical issues involving the definition and use of interfaces, such as how to implement multiple interfaces and how to combine interfaces and class hierarchies. After a detailed look at generic interfaces, the chapter ends with a discussion of interface design and factoring guidelines.

Separating Interface from Implementation

In both C# and Visual Basic 2005, the reserved word interface defines a CLR reference type that can’t have any implementation, can’t be instantiated, and has only public members. Saying that an interface can’t have implementation means that it’s as if all the interface’s methods and properties were abstract. Saying it can’t be instantiated means the same as if the interface were an abstract class (or MustInherit in Visual Basic 2005). For example, this interface definition:

public interface IMyInterface
N$
is almost equivalent to this class definition:

public abstract class MyInterface
N$In traditional object-oriented programming, you typically use an abstract class to define a service abstraction. The abstract class serves to define a set of signatures that multiple classes will implement after deriving from the abstract class. When different service providers share a common base class, they all become polymorphic with that service abstraction, and the client can potentially switch between providers with minimum changes. There are a few important differences between an abstract class and an interface:

• An abstract class can still have implementation: it can have member variables or non-abstract methods or properties. An interface can’t have implementation or
member variables.

• A .NET class can derive from only one base class, even if that base class is abstract. However, a .NET class can implement as many interfaces as required.

• An abstract class can derive from any other class or from one or more interfaces. An interface can derive only from other interfaces.

• An abstract class can have nonpublic (protected or private) methods and properties, even if they are all abstract. In an interface, by definition, all members are public.

• An abstract class can have static methods and static members and can define constants. An interface can have none of those.

• An abstract class can have constructors. An interface can’t.

These differences are deliberately in place, not to restrict interfaces, but rather to provide for a formal public contract between a service provider (the classes implementing the interface) and the service consumer (the client of the classes). Disallowing any kind of implementation details in interfaces (such as method implementations, constants, static members, and constructors) enables .NET to promote loose coupling between the service providers and the client. Because there is nothing in the contract that even hints at implementation, by definition the implementation is well encapsulated behind the interface, and service providers are free to change their implementations without affecting the client. You can even say that the interface acts like a binary shield, isolating each party from the other.

Because interfaces can’t be instantiated, .NET forces clients to choose a particular implementation to instantiate. Having only public members in an interface complements the contract semantics nicely: you would not want a contract with hidden clauses or "fine print." Everything the contract implies should be public and well defined. The more explicit and well defined a contract is, the less likely it is that there will be conflicts down the road regarding exactly what the class providing the service is required to do. The class implementing the interface must implement all the interface members without exception, because it has committed to providing this exact service definition. An interface can extend only other interfaces, not classes. By deriving a new interface from an existing interface, you define a new and specialized contract, and any class that implements that interface must implement all members of the base interface(s). A class can choose to implement multiple interfaces, just as a person can choose to commit to multiple contracts.

Customer Reviews

First Class
This book covers many of the most difficult and obscure aspects of the .NET framework with the level of clarity and authority that has become the trademark of its publisher. It achieves this by breaking each topic down into detailed sections which examine the precise rationale behind various classes and illustrate each point with a concise code example.
I personally find understanding the 'why' is essential to understanding the 'what' and this book does an admirable job in explaining the reasons why many aspects of the .NET framework are the way they are.
I would not recommend this book if you are just starting out, as it makes no compromises about the level of understanding required, but for advanced users building real distributed applications, this book is invaluable.

Solid Foundation for .NET Development
This is an excellent book. The choice of subject matter, the order of the chapters and care with which he emphasises some of the most important patterns (e.g. Finalization/Dispose) make this the book I would choose, if asked to select just one book to give to a new .NET developer.

Juval Lowy writes so well, too. Personally, I prefer technical books which are not flippant and playful, but this book isn't stilted or dull, either; it has an engaging style, and the material flows naturally.

Highly recommended. Buy it, read it.

A bit too abstract...but all .NET developers should read it
I've had to update my previous review of this book for the 2nd edition for 2 reasons:

1) The 2nd edition is better
2) It all makes much more sense now

That said my previous remarks about the book being dry, lacking in context, and reading like a thesis still stand. Even if you think you're a good .NET programmer then it's still very likely that this book will perplex (and possibly bore) you. That said you should read this for no other reason than Juval Lowy wrote it and he knows what he's talking about. He is, arguably, the best .NET guru on the planet and he wants us all to be more disciplined and professional in our .NET development, which is a good thing.

My suggestion is that you get a copy of this book in the first instance to cure your insomnia. But I guarantee that if you are a conscientious developer, you will find yourself referring back to it again and again (and wishing you were that clever). If we all read this then the quality of .NET apps would improve drastically and governments might not waste half a billion quid on systems that don't work.

I still wish it had more pictures and simple contextual explanations though!