Maybe I'm not seeing it... Let's look at the example in the first
link provided above. Here it is: [...]
Okay, so first let's make something clear: that code doesn't use
delegates. It uses an abstract class, and in fact it uses the abstract
class as an interface (suggesting that it should in fact have been an
interface, but we'll leave that criticism of the example aside for now
) ).
Now, the interface -- I mean, abstract class
-- does happen to be a
single-method class, and in that respect is very similar to a delegate (in
the same way a delegate is similar to a single-method interface, as I
mentioned before). But you should be clear that the only reason that link
is pertinent here is that it discusses a particular _design_ pattern that
could be implemented using delegates. In that particular example, the
actual implementation uses an abstract class instead.
Now, that said...if we treat the abstract class sub-class as a delegate,
we can in fact make some useful observations about the code sample. So,
let's do that...
[...]
Why couldn't you just define 3 new methods, as shown below, and get
rid of the "SetSortStrategy":
studentRecords.QuickSort();
studentRecords.Sort();
studentRecords.ShellSort();
studentRecords.Sort();
studentRecords.MergeSort();
studentRecords.Sort();
First point: if the "QuickSort()" method actually sorts the list, then
calling "Sort()" again after doesn't make sense. So let's assume that in
your modification, you intend for the "QuickSort()" method to simply set
the sort strategy rather than sorting the list.
With that in mind, if you wrote the code as you've modified it the
SortedList class would need to anticipate all possible sort strategies and
provide specific methods for each one. Using an abstract class as shown
on the web site (or an interface or a delegate as is also possible) the
SortedList doesn't need to know _anything_ about the specific sorting
technique. It just needs to know that when the client of the SortedList
class wants to order the list, it will provide a method that takes a
single ArrayList as an argument and returns void.
An abstract class, an interface, and a delegate all provide different
mechanisms for this kind of declaration.
If and when the SortedList class then wants to sort itself, it will simply
call that provided implementation to do the work. Again, it never has to
know _how_ that work is implemented. It just declares the method
signature that it will require for doing the work, and it delegates the
work to code implemented elsewhere (and quite possibly at some much later
time).
In fact, it's from this delegation that the word "delegate" comes from.
If you wanted to add another algorithm, such as: BubbleSort(), you
would still need to add this algorithms to the code, and compile it.
I've heard that one of the features of delegates is that it is is more
"dynamic"....doesn't seem to dynamic to me?
It seems very dynamic to me. Note in on that web page that each
implementation of the sorting strategy is a completely different class,
and that the SortedList class doesn't need to anything about those
specific implementations. It knows the abstract base class, and nothing
else.
This means that anyone can use the SortedList class, providing their own
SortStrategy implementation. That implementation can be defined anywhere,
at any time. The implementation can do _whatever_ it wants, and
SortedList never has to worry about the exact implementation.
Delegates work in very much the same way. Something can declare a
delegate type, using that type in its own code, without there being any
implementation of the delegate type at the time the using code is
written. The delegate implementation can be provided later, at the
convenience of whatever code uses the code specifying the delegate type.
As long as the implementation matches the signature specified by the
delegate type, code using the delegate type will compile. (There may be
additional specifications on the implementation, as is the case with
comparison delegates -- that is, a comparison delegate is required to
follow some basic consistency rules for sorting to work).
Pete
