Какова хорошая практика для построения отношений между компонентами в Unity?

Question

Когда я пытаюсь продумать игровую архитектуру в Unity, я сталкиваюсь со следующей проблемой: существует несколько способов построения отношений между компонентами, и я не могу понять, какой из них является наиболее оптимальным.

Например, у нас есть компонент GameplayObject со следующими параметрами

public class GameplayObject : MonoBehaviour
{
    // every gameplay object has chanse of appear on board
    [SerializeField, Min(0)] int m_ChanseOfAppear = 0;

    public int ChanseOfAppear => m_ChanseOfAppear;

    //every gameplay object may be destroyed
    public virtual void Destroy()
    {

    }
}

Метод уничтожения может быть выполнен после пользовательского ввода (щелчок или перетаскивание - только несколько типов ввода), или другой объект игрового процесса может выполнить метод уничтожения. Например, у нас есть следующий компонент TapBehaviour

public class CustomDestroyer: MonoBehaviour, IPointerClickHandler
{    
    public event System.Action OnTap = delegate { };

    IPointerClickHandler.OnPointerClick()
    {
         OnTap();
    }
}

У нас есть конкретный GameplayObject (например, CustomDestroyer), который должен уничтожать объекты конкретным способом. И теперь для нашего компонента ввода нужна зависимость

[RequireComponent(typeof(TapBehaviour), typeof(BoxColiider2D))]
public class CustomDestroyer: GameplayObject 
{
    TapBehaviour m_TapBehaviour;
    TapBehaviour TapBehaviour
    {
        get
        {
            if (m_TapBehaviour == null)
                m_TapBehaviour = GetComponent<TapBehaviour>();
            return m_TapBehaviour;
        }
    }


    public override void Destroy()
    {

    }
}

Но мы можем сделать это прямо противоположным образом: унаследовать CustomDestroyer от TapBehaviour и использовать GameplayObject-подобный компонент.

Итак, главный вопрос - как вы строите архитектуру своих проектов? Когда вы используете наследование компонента, когда используете только компоненты? Может быть, я теряю несколько более предпочтительных способов?

Чем больше вы мне объясните, тем больше я буду вам благодарен!

И извините за плохой английский, просто учу его.

Answer 1

Unity предлагает большую степень свободы в отношении архитектуры, и иногда бывает подавляющим, когда вы можете успешно делать вещи разными способами, и все это будет работать. Что касается вашего вопроса - с точки зрения проверки будущего я бы склонялся к использованию отдельных компонентов (так называемая единая ответственность), свободно связанных между собой с помощью интерфейсов (таких как IDestroy вместо конкретных типов), идея состоит в том, чтобы, по возможности, избегать взаимозависимости компонентов.

Но в большинстве случаев наследование с переопределениями будет в порядке, и рефакторинг часто бывает безболезненным (и есть много способов автоматизировать задачи редактора, если вы заходите слишком далеко по одному из переулков), поэтому мой совет: не надо усложняйте вещи, делайте это как можно проще, но не проще

Answer 2

Из моего опыта работы с Unity вы должны точно знать, что вы хотите сделать, и возможные будущие реализации, а затем найти способ сделать это, и это не ограничивает ваши будущие реализации.

Там нет ОДНОГОспособ связать вещи в Unity, это часть его простоты использования.Все заканчивают тем, что делают по-своему.

Попробуйте найти решение, которое уравновешивает читабельность и эффективность, и придерживайтесь новейших компонентов, которые обычно лучше в целом.

Редактировать: Забыл сказать, что есливы - программист, старайтесь не злоупотреблять силой сценариев, так как Unity была разработана для того, чтобы избегать кода.Пользовательский интерфейс имеет множество опций, которые по сравнению с написанием кода кажутся волшебными.