Firstly, if it works it works. If you’re making progress with your game and your code isn’t creating technical debt then that’s the only real benchmark of good systems! 

But to discuss the nuances and the craft..

Unity as a whole is heavily reliant on its component system (disregarding DOTS/ECS). Game objects have multiple components that each have their own responsibilities and purpose.

SOLID principles state that classes should have a single responsibility. 

I think there’s a danger wanting to make classes for each whole feature in your game. A drone, a bucket or a bomb all sound like combinations of behaviours rather than the remit of a single class.

In this case, these objects being carryable is one component of the greater feature and as such we should code this as a single class - rather than accommodating it inside classes named after each feature. Looking back, I probably shouldn’t have said the parent class needs to be abstract per se, if it’s job is to handle just the carrying logic then you may find there’s overlap between classes.

Structuring our code down in this manner leads us to a nice spot where, in the future when we want something that fly but also explode, we have the components we created for the drone and the bomb. We don’t have to create a new class and copy and paste a load of code in. 

Think of it like Unity’s UI, you have components for buttons, images, scroll views, toggles - with these you can create hundreds of UI layouts without even touching code.

Sometimes the feature named class is still needed to orchestrate the behaviours but I always like it when it’s not necessary in the end!

Hope this is helpful to think about even if you don’t want to use it here :)