KISS vs SOLID, what and when to cook?

Question

OOP

Hello!
Based on a video about the implementation of FizzBazz in JS, I wondered what is really easier to maintain, a dozen lines of KISS ("structural approach")

spoiler

or 60 lines of OOP code for SOLID ?

spoiler

In order to comprehend the OOP example and understand the author's idea, you need to strain, especially when you do not see the author's diagrams and explanations. Otherwise, after the first change, the code will no longer be SOLID.
As a result, it is more difficult to read, it is more difficult to understand, and the juniors are not allowed to access such code at all. And how can this be called more maintainable code?

It is clear that this is a synthetic example and in the real world the tasks are more difficult. But the gap between SOLID and KISS will be about the same. Or am I wrong and say 1000 KISS lines will be harder to maintain than 6000 SOLID lines?

Let's talk about how to draw the line between SOLID and KISS?

PS
Not bad, but not sufficient, a comment on this topic https://softwareengineering.stackexchange.com/a/367100
UPDATE:
I can provide the code only in such a video. The author of the video did not provide the source code.

Answer 1

Firstly, now the moderator will bang your question for violating paragraph 3.8 of the rules. Secondly, paradigms, approaches, patterns and principles are tools for managing the complexity of the code base, and the tool must be chosen according to the task - you should not wind up a multi-level abstraction on FizzBuzz. Thirdly, KISS does not rule out SOLID.

Answer 2

First KISS: decide if you want to make the code complex or if you can get by with a simple solution that is easy to read and maintain.
If it is clear that it will be difficult to read and maintain a sheet of procedurals, we begin to split up the logic, and SOLID helps us in this - it is he who determines the boundaries of the code responsibility areas and allows minimizing the links between the designed classes.
Finally, having decided on the architecture, we return to KISS again within each class, without overcomplicating its internal life beyond the tasks that it must solve. Thanks to the use of SOLID a level above, we can painlessly redo all the giblets of this class if the tasks change and the KISS solution stops working, without refactoring the rest of the code.
No contradictions.