Just need some better understanding for decoupling

[Brandon_Richards]

So if we’re decoupling code – how come the Fighter.cs still has

GetComponent<Mover>().Cancel();

Am I confused about the point of decoupling code from each other? I must be.

In my mind I thought decoupling meant there wouldn’t be any reference between Script A <-> Script B and vice versa. But, instead, when we need them to speak to each other we’d use a means of say ActionScheduler a third script to tell either script the information that would’ve been present in the scripts before the decoupling process.

Is it because that Mover doesn’t reference Fighter that it’s technically no longer coupled even though Fighter still uses it to get information about Cancel()?

[Brian_Trotter]

@Brandon_Richards

Is it because that Mover doesn’t reference Fighter that it’s technically no longer coupled even though Fighter still uses it to get information about Cancel()?

Essentially, yes.
Design problems begin to arise when you get circular dependencies. You will always have one way dependencies. In this case, Fighter uses Mover to accomplish the movement portion of it’s code. The problem can arise when Mover also depends on Fighter… Dependencies should be in a one-way direction. Many classes depend on Mover (PlayerController, AIController, Fighter), but Mover doesn’t depend on any of these classes.

Ideally, one might want to abstract things even further, perhaps creating an IMovement interface. A flying character, for example, might have it’s own Mover type class to manage flying instead of using the NavMesh. The interface would designate that an IMovement would have a StartMoveAction method, a Move Method, and also be an IAction. Fighter would then get the IMovement component instead of Mover. We’re not delving into those types of mechanics in this course.

Down the line (in Shops and Abilities) we will be implementing abilities which will rely much more heavily on the ActionScheduler/IAction interface.