Understanding C# Events, Delegates and Lambdas – New Pluralsight Course

image


C# continues to grow in popularity attracting more and more developers looking to build Web, desktop or mobile applications targeting a variety of platforms. As developers learn the language the concept of events, delegates and lambdas tend to trip some up and generate a lot of questions. For example, what are delegates and how do they actually work? Would you ever create a custom delegate and in which scenarios? What’s a lambda used for and why would someone choose a lambda over other techniques? How do you write custom delegates/events and use them in C# classes to provide notifications to other components in an application? These are just a few of the questions that many struggle to understand.

To help answer these questions and clarify the role of events, delegates, EventArgs, lambdas and other related features, I’m excited to announce the release of a new Pluralsight course titled C# Events, Delegates and Lambdas that provides simple explanations that show the big picture and how events, delegates, lambdas and other components fit in. If you’re interested in gaining a more thorough understanding of how these C# technologies work together then you’ll definitely want to check out this new course!

image

Key topics covered in the course include:

  • The role of events, delegates and event handlers
  • How to create custom delegates and events
  • Techniques for raising events (without raising errors)
  • Different techniques that can be used to handle events
  • The role of lambdas and how they provide a concise way to write code
  • Built-in .NET delegates that can be used in your custom C# classes
  • Using lambdas with delegates to provide flexibility in an application

comments powered by Disqus

3 Comments

  • Hi, Thanks a lot, it will be best resource for me.

  • Hi Dan,

    Very nice explanation. Only thing which I feel is missing is mentioning of two important difference between events and delegates:

    1. Events can't be invoked from outside of the containing class where as delegate can be.

    2. Events can be enforced by including them into interface where as delegate can't be part of interface.

    Hope you'll include these in your upcoming sessions sometime.

    Thanks,

    Vinay Verma

  • Great points Vinay. I had someone ask about major differences directly on the Pluralsight course page and here was my response (see below). It basically echoes what you're saying. To be honest I don't know that the points are that important to call out because if devs follow convention then events are used for notifications and delegates are used to route data around. Sure, delegates could be used instead of events for notifications but I'd argue that's breaking convention. But, it's always good to know the granular differences. :-) Here was my response to a question about key differences:

    Events really are syntactic sugar around delegates but they're a standard fixture in .NET applications. Although you don't have to use events per se, you get a lot of benefits by using them such as direct support in Visual Studio for components/controls that define events (the lightning bolt icon in the properties window, double-clicking controls to handle default events, etc.), intellisense support makes it easy to identify events, and in general devs are used to working with events and find them easier to use than raw delegates when trying to listen for specific notifications. A few other things off the top of my head:

    1. Events can only be invoked from the class that defines them. Not the case with delegates. Whatever object has a reference to a delegate can invoke it.
    2. Events provide more control over adding/removing to/from a delegate. A more advanced scenario and not that common but something that can be useful in specific scenarios where that type of control is needed.
    3. Events provide a consistent signature that event listeners can count on (object sender, SomeTypeOfEventArgs e) whereas delegates don't have that consistency. This is part of the reason events are used so much across .NET objects - it drives consistency.
    4. You can define events in interfaces. You can't define a delegate (the actual definition of the delegate) in an interface.
    Although you can certainly use delegates directly (and there's nothing wrong with that), events are the "standard" way to allow listeners to attach to notifications and expected by people consuming objects that expose notifications in .NET. I use delegates anytime I need a placeholder for a method and want to pass that around between methods as in some of the demos in the course. Any time I need to expose notification functionality in an object I go with events since it's easier to grasp by people in general and the standard .NET approach for that type of activity.

    Dan

Comments have been disabled for this content.