Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice

Observer Pattern with Delegates vs Event-driven programming

Discussion in 'Scripting' started by davidhfw, Apr 28, 2017.

  1. davidhfw

    davidhfw

    Joined:
    Aug 17, 2016
    Posts:
    77
    I was reading up on observer pattern to refactor codes in the Update(), which lead me to some write-up on event driven programming. For event driven programming, three key components were mentioned;

    1) Event Listener - object that wants to be notified about an event when it happens.
    2) Event Announcer - object that detect when the event occurs and announce it to all listeners to be notified.
    3) Event Manager - Singleton object that accepts notifications of events and publish the notifications to all appropriate listeners.

    So the tutorial went on with writing up the codes for the 3 components.

    Question is why go through all these when we could have just use delegate event object and register to the delegate to be notified of the event? Net result seems to be the same (or not) ?

    In the observable object, have the delegate declared and initialized:


    Code (CSharp):
    1. public delegate void MyDelegate();
    2. public class Target : MonoBehaviour
    3.   {
    4.   public event MyDelegate myDelegate;
    5.   }
    6.  
    7. // Run myDelegate when required.
    8. }
    In the observer object, register to the event:


    Code (CSharp):
    1. public class MyObserver : MonoBehavior
    2. {
    3.   private Target target;
    4.   void Awake()
    5.   {
    6.   target = FindObjectOfType<Target>();
    7.   }
    8.  
    9.   void Start()
    10.   {
    11.   target.myDelegate += ReactToEvent();
    12.   }
    13. }

    Appreciate your thoughts and comments on this.

    Thanks!
     
  2. J0hn4n

    J0hn4n

    Joined:
    May 11, 2015
    Posts:
    24
    well i think its the allocation. using Interfaces its just a method call.
     
  3. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    The key reason here is to decouple the two parts of your code base.

    Under a Broadcaster, Receiver system the Receiver must know about the Broadcaster.

    Under the Broadcaster, Manager, Receiver system the Broadcaster and the Reciever do not know about each other. Instead they both know about the Manager. This can be really useful when you need to couple multiple disparate systems.
     
  4. BlackPete

    BlackPete

    Joined:
    Nov 16, 2016
    Posts:
    970
    It might be easier to think in terms of multiplayer programming.

    Suppose you're playing a chess game with someone. When you touch a chess piece, it glows. Your opponent should also see your piece glow on their end as well.

    So let's break that down. What should happen when you touch a chess piece?

    Your event creator tells the broadcaster that a chess piece has been touched (which one, and by whom).

    You have listeners who tell the broadcaster, "Hey if TouchPieceAction happens, I want to know about it!"

    One of those listeners is the network manager (or the broadcaster itself can be the network manager). The TouchPieceAction is packed into a network message to send to the opponent's network manager.

    The opponent's broadcaster receives the TouchPieceAction from you, and broadcasts that to all its listeners.

    One of those listeners is the glow shader thingamajig that activates around that specific chess piece using a specific color (along with maybe a name label) representing who touched it.

    In the chess example above, the glow shader thingamajig only has one place to connect to so it doesn't need to care about where the TouchPieceAction came from (either via input, UI, network, whatever).
     
  5. Owen-Reynolds

    Owen-Reynolds

    Joined:
    Feb 15, 2012
    Posts:
    1,924
    The regular internet loves to talk about Design Patterns. "Observer Pattern vs. Event Driven" will probably get some fun hits.

    But a manager in the middle is good for consumable events. Touches and clicks, say. Instead of sending the click out to everyone, a manager could ask them in turn until one wants it.