You can however nicely isolate the code which has behaviour changes for each vendor.

Typically resulting in ravioli code instead. Or an explicit state machine, even worse to follow.

https://en.wikipedia.org/wiki/Spaghetti_code#Ravioli_code

(Wanted to link C2 wiki but it's a goner.)

You cannot fix essential complexity with any kind of design. If there are options in design, your code will reflect them at some layer. You might want to suggest, say, Component or entity-based or other design, or mixins, or other object level patches for conditionals.

Spaghetti if otherwise well structured is quite understandable. The more advanced versions? Not nearly. Spaghetti is explicit at least.

> You cannot fix essential complexity with any kind of design. If there are options in design, your code will reflect them at some layer.

That’s certainly true; my favorite method at the moment for this sort of thing is to make it data-driven: have a structure that contains all of the parameters that change based on vendor (including enums/flags for optional behaviors) and a single process implementation that refers to it when needed.

You end up with a big if-then block. Essentially spaghetti but localized.

A joke I sometimes make is that spaghetti is best of a plate or in a box from which it cannot escape. Otherwise it would spill.

Ravioli does not spill but the relationships become implicit.

Localized is good. It means that the next time there’s a new thing, there’s only one place you need to change to specify its unique set of properties. Often, this can even be removed from the code entirely into a configuration file, so that a recompilation isn’t necessary for every new situation.

> Typically resulting in ravioli code instead.

This is an awesome term and I must admit that I've never heard it before.

It does apply to a lot of code that I've seen, and let's face it, written, over the years.

I think there's area in between 1500 line methods and ravioli code