Solid Programming - No Thanks

"Program until you NEED abstraction" is on point. I was having this debate at work yesterday, and I said something very similar. Unless you're a savant, who can architect a program entirely in your mind, the most logical thing to do is to write code until you realize that abstraction would be beneficial, implement it, and continue writing code. To do otherwise is just wasting time in my opinion.

liquid programming

This topic always reminds me of the famous Miles Davis quote: "Learn the score, then throw it away" is a quote often attributed to jazz musician Miles Davis. The quote emphasizes the importance of mastering the fundamentals and techniques of one's craft, but then being able to move beyond them and improvise freely.

I work in a game engine project which was initially designed with SOLID in mind. At the beginning a lot of those abstractions just seemed unnecessary. However, as the project grows and becomes really big it starts to pay off! It is just a pleasure to work with such a project. For example the basic windowing system was changed two times already from QT to SDL and than to GLFW. Nobody new this would be so at the start. However, as the windowing code is abstracted in a separate static library and communicates with core through small interfaces like IInputObserver which calls abstract functions like OnKeyDown/Up etc. changing the whole windowing system takes a few hours and produces no bugs AT ALL! This is just a simple example. The whole project is like that. A big project created with SOLID in mind is a pure gem!

Liskov doesn‘t say that you want to have a lot of subclasses. It just says that if you write a subclass, you better don‘t do unexpected things there that breaks code which codes against the base class. If you never write any subclass, you trivially follow the principle.

This reminds me of the book A Philosophy of Software Design. It states that you should only create an abstraction if it reduces the complexity of the system. It calls abstractions that are a net drain on the simplicity of the system "shallow" and ones that are a net gain as "deep". The book also acknowledges that this means that one piece of code may have to do multiple types of tasks.

Generally Liskov principle states "dont let the tail wag the dog", so hierarchy of classes should be in sane composition with each other. Rust traits are the good example of following the principle

The comment about knowing when to abstract and when not to abstract really resonated with me. My sense is that the SOLID principles become more valuable as your app gets larger and more complex. When you are first writing a small app, many of the principles cause more problems than they solve. When it is easy to execute on them, great, do it. When it is awkward or difficult to do it, wait until you actually have a need to actually do them. Many times, the best choice is to just be mindful about how you can avoid closing doors on your design unintentionally.

I think ThePrimagen should push his new paradigm: SOLIDR, single responsibility, etc, etc, etc and then R for "If all else fails just RAW DAWG IT IN THERE WHEREVER YOU WANT"

This is essentially the programming version of the Platonic Idealism vs. Aristotilian Realism debate