In a ride-sharing service where fare calculation branches on a raw vehicle type string, which principle is being violated and which pattern fixes it?

Branching on a raw type string inside a shared calculation method violates the open-closed idea that existing, tested code should not need to be reopened every time a new variant is added -- supporting a new vehicle type means editing that same if/else chain directly. It is closely related to a Liskov substitution problem too, since there is no real type hierarchy in play at all: every vehicle is the same concrete class wearing a different label, rather than a genuinely substitutable subtype. The fix is to replace the string with a real abstract method on an abstract Vehicle class -- each concrete vehicle type answers for its own fare-per-kilometer polymorphically, and adding a new vehicle type becomes a small new class with no existing code touched at all.