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.