Interfaces

[SHEePYTaGGeRNeP]

Maybe a dumb question, but why is Command an abstract class and not an interface?

[Naphier]

Not a dumb question at all. This could certainly be an interface in this example. However, the only reason to do so would be if we had a class that needs to inherit from some other base as well as implement the Command structure. Usually I'll go with abstract because it's easy to add more to it. Also the examples I see out there usually use abstract classes. The examples I see out there also use the term abstract class and interface interchangeably. This is because they are usually talking about an interface in the traditional sense instead of the C# interface structure.

Another reason I'll likely use abstract in the examples is that I don't want newcomers to think that they are tied to using an interface for a pattern. Most of the times when you write your own implementation of a pattern you won't have such a bare bones base abstract class.

But you're absolutely right. The Command class could definitely be an interface in this example.

[jason-storey]

I'd actually be on the interface camp personally.

It is a matter of good principle.

people traditionally think of a single project as an isolated box. but realistically what happens is when a particular features gets big enough to be used 3-4 times it becomes worthy enough to be abstracted out into a common library.

I tend to consider things like an ICommand (or more specifically an IActorCommand with a gameObject argument)to be a prime contender.

because you could build a dll called MyLib.Common.Contracts and then drop that lightweight contract dll into any project, then build commands that can seamlessly work with every project you have as the base is the same. no recompiling etc.

then you structure plugins that reference the contracts, e.g

MyLib.Commands.UI
MyLib.Commands.TankLocomotion
MyLib.Commands.PlayerLocomotion

or whatever.

or if someone had an external API they could reference your contract project without referencing any of your implementation code.

As a rule when designing design patterns you lean on the language strengths at your disposal,
e.g making a undo-redo command implementation in javascript would make heavy use of the power of closures while a c# version might make heavy use of interfaces and generics.

you are teaching people how to use Design patterns with unity after all, might as well lean into the language strengths.

and as a final note, always favor composition over inheritance. what if someone wanted their own base class, do they have to use yours?

what if their command is like a game power?
and rather than actually BE a command it is actually part of some other system they have

IPower{}

APhysicsPower : IPower

and so on, but this power can also be a command, they might

APhysicsPower : IPower,IActorCommand

I mean, logically a power ISNT a command, so it should inherit from Command but it can decide to conform to a Command call to add support to another system,

It would be infuriating if IDisposable, IEnumerable, ICollection or others were abstract classes.

What if something later is both a Command and another pattern like a factory/builder of some kind? that would literally be impossible to do. to support both echosystems.

[Naphier]

You are correct, in most cases an interface may be most appropriate. I guess I just always feel like they are going to limit me too much, but that's me thinking too much from inheritance when I should be thinking from abstraction.