В чём отличие Interface от Class? c# Unity

Question

В целом, худо бедно я понимаю в чём отличия. Меня вот что интересует, что может интерфейс что не может класс, для чего именно интерфейс нужно использовать, а не класс как какой то шаблон. Чем больше читаю про него тем более не понимаю. В какой ситуации лучше использовать Интерфейс, а не Класс. Может я просто не дорос до него и не понимаю, но я чувствую что мне надо знать с чем его едят

Answer 1

Класс - шаблон для объекта, интерфейс - шаблон для класса или его части. Вопрос хоть и странный, но хорошо что вы им задались, и лучший способ найти ответ - почитать готовые статьи про интерфейсы на эту тему.

Вот ситуация, есть 3 абстракции. Думаю, объяснять не надо.

abstract class Fighter
{
    public abstract void Fight();
}

abstract class Wizard
{
    public abstract void Spell();
}

abstract class Healer
{
    public abstract void Heal();
}

Теперь из них как-то надо сделать классы Shaman, который может Fight и Heal, и Sorcerer, который может Spell и Heal.

Ничего не выйдет, наследоваться можно только от одного родителя

class Shaman : Fighter, Healer { } // ошибка

Теперь берем интерфейсы

interface IFighter
{
    void Fight();
}

interface IWizard
{
    void Spell();
}

interface IHealer
{
    void Heal();
}

А вот так получится. С интерфейсами говорят не "наследовать", а "реализовать". Реализовать более одного интерфейса можно без проблем.

class Shaman : IFighter, IHealer // ОК
{
    public void Fight() { }
    public void Heal() { }
}

Это конечно далеко не все особенности интерфейсов, изучайте дальше.

Answer 2

Если ты писал обработчики для событий UI в Unity это очень показательный пример. IPointerDownHandler, IPointerEnterHandler, IDragHandler и т.д. хрен знает что в их реализации, каждый раз что-то свое, классы тут никак не помогут.

Тоже самое на самом деле касается привычных нам магических методов Start, Update, OnDestroy и т.д. Их много, но используются меньшинство, будь это абстрактные методы абстрактного класса, реализовывать пришлось бы все, а будь они virtual пустышки тратили бы ресурсы. В Unity они реализованы конечно же не через интерфейсы, а рекурсией для упрощения порога входа и понятном всем ограничивании на MonoBehaviour, но рекурсия это костыли, в идеале должны быть интерфейса.

Вообще нет вопроса: почему в этом случае нужен interface, а не class. Ситуация ровно противоположная, почему class, а не interface. Только если наследуется реализация, да и то реализация может быть реализована классом который прописан в поле интерфейса типа:

public interface IMovable {
    Movement Movement { get; }
}

public class Sheep : IMovable {
    public Movement Movement { get; private set; }
    public Sheep () => Movement = new WalkMovement();
}

public class Frog : IMovable {
    public Movement Movement { get; private set; }
    public Frog () => Movement = new JumpMovement();
}

public class MoveInput  {
    private IMovable _target;
    private void Update () => _target.Vector = new Vector2(horizontal, vertical);
}

Но да наследование в моем примере все-же есть, WalkMovementи JumpMovement наследуется от Movement, но может быть и без наследников или даже интерфейс, то-есть интерфейс говорящий что, у класса есть поле с неким интерфейсом) Например IStats и IStatsHolder.

Поэтому в "чистом коде" наследование используется НАМНОГО реже интерфейса. А одна из самых главных фишек интерфейса, что если потом нужно будет подменить одну реализацию на другую, новую, даже если это не планировалось, то это черезвычайно легко сделать, или когда реализация откровенно тестовая/временная, placeholder короче, с классами в этих случаях может быть(скорее всего) полная жопа.

БЛОГ НА HUSL

В чём отличие Interface от Class? c# Unity

Ответы (2 шт):