DRY principle

[Stopa]

At this point the same code for destroying the object when it dies is repeated at three different places (and it really does not belong in either): Unit, UnitSpawner and UnitBase, which is a clear violation of the Don’t Repeat Yourself principle. If we later on decide to e.g. use object pooling instead of destroying the object, we need to rewrite all these scripts. Moreover, if we would for example decide to add destructible environment (large rock obstacle), we would have to write the code again. Last but not least, we would not have conflicting behaviour, so we could make e.g. a Unit which is also UnitSpawner and we would not have to temporarily comment out the destroy line in UnitSpawner.

Wouldn’t it be cleaner if we just had a simple Death : NetworkBehaviour component (just as we do with Health) that handles the object destruction and added this component to all destructible objects?

[vendolis]

I was thinking about that myself for a little. I think in this case, it is warranted that they are handled at the locations they are. DRY mainly looks at things that will require you to change multiple locations when you change one of them. (e.g., If you do a complicated calculation of a value, you want only to do it in one place, else you will get errors… or you have a logic that has to be the same in multiple places) …
Here it is different; each of these locations deals with death (possibly) differently. And changing how a unit dies does not require a change to the way a building dies. Nor does a general building has the requirements of the base dying.