What happens if you replace the interface with an abstract class?

public abstract class Action: MonoBehaviour
{
     public abstract void Cancel();
}
public class Move : Action { /*magic code here*/}

public class Fighter : Action { /*cool code right here*/ }

public class ActionScheduler : MonoBehaviour
{
        //private IAction _currentAction;
        private Action _currentAction;

        //public void StartAction(IAction action)
        public void StartAction(Action action)
        {
            if (_currentAction != action)
            {
                if (_currentAction != null)
                {
                    print("cancel " + _currentAction);
                    _currentAction.Cancel();
                }
                _currentAction = action;
            }
        }
}
It seems to be the same but I'm not sure. Does it change something?
I lack theory on SOLID principles.

In general, this is acceptable. In the Shops and Ablities course, this will break, as we will have an AbilityData class (not a MonoBehaviour, can’t be a MonoBehaviour) that leverages the power of IAction to allow delayed click targeting…

Usually, the best time to use an abstract class over an interface is when you have some defined code you always want the child class to inherit in addition to the abstract code. Whenever possible, you should prefer an Interface over an Abstract class.

2 Likes

Also, classes can implement multiple interfaces, but only one abstract class.

2 Likes

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms