I created my own SOLID principles

TL;DR: Uncle Bob liked this :)

I am a big fan of SOLID! Not only that, time after time, I elaborated my own words to express SOLID principles. And as you can see below, I noticed it is almost all about embracing the #change, mastering the #change and anticipating the #change..

[S]: a Unique decider of #change!

Whenever you pack some of your code into a module (i.e: function, class, package..), there must be a unique thing(often a business department or tech dependency), that will?force?you to #change the code of that module. One, and not two, or twenty, only one!

[O]: Minimize touched code if you HAVE to #change

"Open for extension / closed for modification", right?

Well, there is nothing which is open AND closed at the same time, you know! Your code will be ALWAYS open for modification, otherwise, let's apply TripleDES encryption on each of our classes and then delete the key. Thus we have a really closed module.

That's why I believe "closed for modification" should be suffixed with: "except the very tiny piece that will be used to connect the old code with the newly added one"

[L]:Your problem is not mine

OK this principle has the scariest words, but from my point of view what it wants us to avoid is writing sub-classes which add rules to the ones it inherits from (that's rude right?), and hence my way to rephrase this principle as "Your problem is not mine". For example, suppose you ship a package to your customers, who are developers like us. And one day you provide them a new version consisting of a sub-module of the old one, but with a bunch of subtle restrictions and rules. You only add them to solve some of your own code's problems. How would you imagine the face of that poor developer trying to figure out WHY dozens of classes and weird checks exist at all? Don't you think that "Your problem is not his problem" ?

[I]: Don't pull all your eggs in one basket

The official version of the principle is: “Clients should not be forced to depend upon interfaces that they do not use.” Again, my intuitive question here is: why?what does it try to troubleshoot?

And my answer is: it clearly fights those hasty guys (including me sometimes) who write those all-knowing interfaces having a dozen of methods. Some ultimate interface called IReadWriteCompress or ReadWriteCompressInterface..

Without even looking into the code, we feel the instinct and the urge to split that big-tank into three small speed-boats, for instance: WriteInterface, ReadInterface and CompressInterface. So one should not pull all his eggs in one basket, or all his methods in one interface!

[D]: Rely on the least #changing dependency

"High-level modules should not depend on low-level modules. Both should depend on abstractions"

Again: why? The answer I could come up with is: "no one wants to depend on loosely changing elements?"

And this makes it obvious to go for dependency on abstractions rather than dependency on implementations (aka low-level modules). Low-Level usually has way more details and information to tell than abstractions. Abstractions only expose the big picture which is supposed to last. Abstractions have less details, which means adapting to their #changes is always easier.

So, that was it, and I would be glad if you could also share your own SOLID versions with me :)

Happy coding!