> 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.
Re:In the Defense of Spaghetti Code (2013)
by AstralStorm on Monday July 22, 2019 @06:56AM
(#20496836)
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.
Re:In the Defense of Spaghetti Code (2013)
by reallydontask on Monday July 22, 2019 @07:08AM
(#20496888)
> 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.
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.