Why should we separate [tank/ tank aiming component/ tank barrel] into different parts?

If we write the code within 1 single class, the code would be less complex, which is good for debugging. And designers can tune their tank within 1 board. So I want to ask: Is there particular reasons why we should separate them? Is it necessary?

Thanks!

1 Like

The code would only be less complex initially. However, as codebases grow you will find that the loosely coupled operation of the functions would become more and more tight as there is no enforced interface between them. This would lead to a spaghetti mess.

2 Likes

Not only that, but lets say you have a tank, with its barrel and aiming component, but also a magnetic coil gun… or a laser turret… things like that.

A laser gun for example would work on a totally different principle. You might not use a suggestlaunchvelocity but just do a ray cast. Or you might have a missile that can do auto-homing. I.e. - no need to actually aim that precisely.

By Seperating the logic to the actual component you can later just replace the component without adjusting (much) of the main tank logic. Especially if you used inheritance by that point (I.e. you might make a UAimableStaticMeshComponent class that inherits from UStaticMeshComponent, and then create a TankBarrel & TankMissileLauncher class based on the UAimingStaticMeshComponent) you don’t need to change any code whatsoever - as long as the public interface is the same it’ll work if you do it right :slight_smile:

3 Likes

Privacy & Terms