ButtonとUnityEventよもやま #Unity

uGUIのButtonとかでおなじみのUnityEventですが、あんまり開発現場では人気がないような気がしませんかね。するよね実際。

だいたい、

TestButtonScene1.cs

using UnityEngine;
using UnityEngine.UI;

public class TestButtonScene1: MonoBehaviour
{
    [SerializeField] private Button sampleButton;

   void Start()
    {
        sampleButton.onClick.AddListener(() => {
            //処理
        });
    }
}

こんな風にコード上で入れちゃう。

コレをButtonのUnityEventでメソッドを呼ぶ形にすると、

TestButtonScene2.cs

using UnityEngine;

public class TestButtonScene2: MonoBehaviour
{
    public void OnSampleButtonClick()
    {
            //処理
    }
}

こんな風に書けるわけで、一見こっちのほうがシンプルだしButtonの参照もなく、コンポーネントが独立してていいじゃーんと思うわけです。

メリットとか

一人で作ってるならともかうとして複数人でコードをいじる場合、ButtonのUnityEventを使うとバグった時にコード上からは追いにくいのですね。

TestButtonScene1.csの場合はコードを読むだけでボタンの中の処理だとわかる。
TestButtonScene2.csに場合はもちろんメソッド名がOn～ButtonClickなんだから分かるだろ、ってなもんですが、その保証はないし。publicメソッドだからどこからでも呼べるわけだし。うっかり貼り間違いとかでもバグることになる。

プログラマはできることならIDEから離れたくない人種(偏見)なのでTestButtonScene1.csが好まれたりするのだと思います。

UnityEventをどういう時に使う？

上でも書きましたが、UnityEventを使うとメソッドの呼ぶ先を貼り付けれるわけですからコンポーネントの独立性を保ちやすいです。

いろんな場所で使って欲しいようなコンポーネントを作る時に効果を発揮するでしょう。汎用性でる。

逆に言えばそうでないなら無理して使うこともないよねって思います。

余談1

Buttonに入れるもう一つのメリットとして、Buttonの拡張を仕込んでおけば「連打」や「同時押し」を抑制できるというのがあります。UniRxとか使うとイイよね。

この辺は特にスマフォ向けだとなにかとバグるし、イチイチメソッドごとに対策いれるのも面倒だしで賞味こっちのメリットのほうが大きいかも。

余談2

AddListenerは何個も入れれてしまうのでウッカリOnEnableとかリフレッシュ処理とかに突っ込むと沢山はいってしまう。この辺も拡張解決したほうが幸せです。