Object-oriented – Do delegates defy OOP

Delegates are used in ASP.NET for binding the events from controls on the page to the functions in your code behind. If we take the ASP.NET button for example, we have the click action, command action, DataBinding action, along with Disposed, INit, Load, PreRender and Unload. All of those have delegates associated with them and if you create a function that does something with it, the delegate will point to your function.

I think the confusion is when you use the delegates. Since ASP.NET MVC3 is built on ASP.NET and is not its own beast. You will still use delegates when using input fields or any of the asp controls even when using MVC. Like maple_shaft says:

Everytime there is a postback to the server, the ASP.NET lifecycle events are fired in order, causing the server side objects to be created, updating the viewstate with the updated information from the client, updating the server side elements with data from the viewstate, executing any server side events that need to be executed, and finally rendering the HTTP response to return back to the client.

The way that the events are executed is through the use of delegates.

Is it possible to gain all the features of delegates by using Strategy design pattern?

Not exactly.

In C#, delegates are used to implement the strategy pattern nicely and easily. Sometimes, virtual dispatch via inheritance is used to implement the strategy pattern because it fits better for the problem. Rarely, overloaded dynamic methods are used.

Java really only has the second as an option at the moment.

It's not really correct to say that the strategy pattern can provide delegate behavior because one is a design pattern and the other is a construct. The whole Turing completeness thing says that Java can emulate delegate behavior, but a number of the delegate's features (capturing local variables, multi-casting) will fall outside of what a Strategy pattern solves.