Alright, you might want to do a test run with 10x the amount of bullets you expect to be there at any time on a phone and see if there is a problem or not. If there is, consider the optimization methods I mentioned.
This is not common. I’d rather expect an interface called “SurfaceInteractionInterface” that implements methods like “WillBounce” “WillDestroy” “WillCauseDamage” “WillPenetrate” on your projectile class. This does however push you into that direction for all projectiles and might limit creativity a bit unless you allow it (laser beam, explosions, splitting projectiles etc.)
Next to consider is where to implement what. A wall is just a wall. It has no functions but to stand there so it usually shouldn’t get any. Each class should deal with its own logic. You could argue that projectiles implement everything projectile related in the projectile class. “Will I bounce of an enemy? Will I bounce of a wall?”. If you do decide to implement that logic on the wall side, what if you require the same logic on a different object? Like bouncing off an enemy?
You could consider making a “SurfaceEffect” class which deals with generic actions like bouncing / damaging actors colliding. It could be an ActorComponent. On your wall you would add the component and pick the bounce effect. on a lava floor you would pick the damage effect. This is flexible for a bunch of uses because you can add it to a wall, enemy or projectile.