koobas.hobune.stream
Using the Delegate Object design pattern in Unity
In native iOS development, one common pattern is the Delegate Object pattern.
The idea is that you've got some common UI component - say, a grid view - but, as it's a common component, it doesn't have any logic about how many rows or columns it should have, or what it should put in each cell, or whether cells are selectable, and so on. So, what it does is to declare an interface that describes all these undefined things, and then ask for an object that implements that interface - a Delegate Object. (It's similar to C#'s delegate functions, but grouping a bunch of functions together into an interface).
I've got a collection of behaviours and objects set up that represent the game's main menu, but I want to keep all the logic for actually starting a new game, loading a game, saving a game, etc, out of there. I figured that the Delegate Object pattern would be good for this; I could declare interface IMainMenuDelegate { void StartNewGame(); void LoadGame(string savePath); } and so on, have the main menu code hold a reference to an IMainMenuDelegate, and have it call it when interesting things happen.
Where I run into problems is wiring up the delegate. I can write a MonoBehaviour that implements IMainMenuDelegate quite happily, but because IMainMenuDelegate itself doesn't derive from UnityEngine.Object, I can't have it show up as a field in the inspector, or FindObjectOfType(), or even GetComponentOfType().
The only option that remains is to wire it up in code. I could do that, but I'd quite like to avoid it if possible - it's not very elegant.
The only other solution I've seen has been to implement IMainMenuDelegate not as a C# interface, but as a MonoBehaviour that contains a bunch of C# delegates. This is kinda clever in that you can call the resulting component as if it were an interface, but it requires quite a lot of funky wireup, and in theory makes it possible for some of the methods to fail to be implemented, if you don't set the delegates. Obviously with an interface you could fail to wire up the delegate object entirely, but at least that way it's all-or-nothing.
Anyone have any ideas?
Have you tried creating an Abstract class that implements the IGameMenu interface and inherits from MonoBehaviour?
I haven't. If I'm doing that, though, then wouldn't that render the interface obsolete? Also my delegate object would need to inherit from the abstract class, so I wouldn't be able to have it inherit from anything else...
It won't make the interface obsolete neccessarily, imagine you may want to have a special type of Game$$anonymous$$enu, that uses the IGame$$anonymous$$enu interface + some other interface. Then you could have an abstract class that uses the IGame$$anonymous$$enu interface and another one that uses IGame$$anonymous$$enu + IGameController (or whatever you come up with). So if you use an abstract class implementing the interface you could still create an abstract class C that inherits from A but also implements interface B.
Angry Ant implemented a solution that demonstrates the use of delegates in the creation of a menu system. The code is [here][1]. He also includes a Unity project based on this code. I cannot fully understand what you want, but I hope that this code might help you :) [1]: http://eej.dk/angryant/general/tipsandtricks/building-a-menu-of-delegates-and-enums/
