Scribd
Upload
4 views

complete-reference-vb_net_6

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
4 views

complete-reference-vb_net_6

Uploaded by

khalid
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

Delegate Events vs.

Adapter Events

At this juncture, it makes sense to stop and ask if such an elaborate delegation construct is necessary, since
.NET provides incredible native support for interfaces. This next section tackles the case of (Adapter)
Interface vs. Delegate.

Delegate Events vs. Adapter Events

Delegates and interfaces are similar, because they both allow an interface to be completely separated from an
implementation. Interfaces let you vary the implementation that can be accessed via a compatible de−coupled
interface. A Delegate specifies the signature of a method in the same semantic terms as an interface. In this
regard, programmers can write methodsthat is, provide implementationthat can be seamlessly coupled with
the Delegate interface.

If you think about it, interfaces and Delegates do the same thing. Thus, if .NET has interfaces, why does it
also need Delegates? There has been bitter debate on the subject in OO circles for many years. Let's
investigate the differences for ourselves, starting first with interfaces.

Interfaces may be limited in their utility for several reasons:

• Classes can only implement an interface once.


• Name collisions between interfaces can preclude a class from implementing multiple interfaces. This
is one of the reasons multiple inheritance is not available in .NET.
• Interfaces are public, and their members are public. You cannot expose the members via any other
access level. This is not a limiting factor for interfaces. If the members were not publicly visible, they
would not be able to function as interfaces. However, it may be a limitation in a delegation or
event−generating scenario.

To overcome these limitations and to allow a Receiver's or Target's methods to be accessed in a delegation
arrangement, we nest an Adapter interface as an inner or composite interface class in a Receiver, or in a
descendent of a Receiver. An Adapter composite provides a number of benefits in a delegation arrangement.
However, often a container such as a form is the source of many events. A form may employ multiple controls
and components. It may have many buttons, combo boxes, lists, timers, multiples text boxes, and multiple
labels.

Thus, if you employ an interface−based event or interfaced− based delegation model, a typical form may
require dozens of Adapter implementations one for every event or delegation instance. The result is an
explosion of Adapters. This may have a negative impact on performance, though in most cases this would not
be too noticeable. But the bigger issue is that it requires you to be doing a lot of implementation and interface
management. In a lengthy application, this could mean managing hundreds of interfaces to accommodate an
extensive event−driven solution.

Delegates are easier to manage for the following reasons:

• First, there is no such thing as a "name collision" in the employment of Delegates. As long as a
method's signature matches the signature in the Delegate, and a return type matches the return type of
the Delegate, you can call its method anything you like.
• Second, while Delegates can't invoke the private members of Receiver objects, it is still possible to
invoke friends or the public methods of Adapters.
• Third, classes can implement as many methods as needed, and the Receiver objects need no special
constructs, such as composite adapter−interfaces, to expose the methods to an event model. Wiring up

490

You might also like