http://www.c-sharpcorner.com/UploadFile/damubetha/solid-principles-in-C-Sharp/
这个印度人写得不错。我来精简一下我的理解：
S：单一责任–这是废话，谁会写ClassForAandB这样的类？在类命名精确的前提下，违反这个原则的代码应该不会出现, 如果非要违反命名，挂羊头卖狗肉，也可以说破坏了关（close to modification）。
O：开关原则–这才是SOLID的基础和精华，写代码都知道要用类的继承封装变化点，这就是开(open to extension)。但是往往容易忽略什么需要关的（close to modification）。从软件开发=代码堆砌的角度看，历史代码能够关上说明其命名精确，实现逻辑稳定，一些类库中几十年前写下而沿用的模块就是成功的关的例子。
L：Liscov是个女人，这个女人也说了一句废话，子类要能够替换父类的工作。对于那种子类的方法完全不做父类方法的工作的做法，本身就是违反方法名的，一定会违反我的命名要精确的前提。违背这个原则也算是违背了close to modification，因为子类modify了父类逻辑(导致不能替换工作），也可以说是没开好（子类本来是父类的extension，但是extend了错误的逻辑）。
I：接口分离原则，大而全的接口是不好的。大接口最好的情况就是实现类的方法里直接return什么也不做地实现接口 ，或者定义一个什么也不干的抽象方法 和抽象类(也算是方法或者类的命名不精确，如果非要定一个AbstractXXX的名，也可以说是一种不好的开的实践，虽然子类也可以算是开放扩展），最坏的情况就是导致违反LSP，例子就是微软的Array类违反了LSP(结果,没关好, Array的IList<T>实现throw exception），直接原因就是没做好Interface Separation。
D: 依赖反转，这是依赖注入的前世吧，首先要破除直接依赖，尽量引入接口。好的代码就是高内聚（High cohesion，也就是开关原则里的关），同时要低耦合（loose coupling,也就是开关原则里的开）。依赖就是耦合，要降低，也就是真正的开好。依赖反转所说的破解依赖的方法就是引入接口，将来的变化点通过类的继承得以扩展（继续堆砌代码，开）。本来存在依赖（没开好）的地方引入了抽象接口之后，变成了开放的可扩展的结构，一下子反转了这种依赖。稍微扩展一些，依赖=>接口化=>便于容器注入实现, 这就是现在流行的依赖注入，把依赖的注入责任从代码中解放出来放到配置里，从而实现了控制权的反转（后期的人可以控制前期固定的代码）。这算是反转进阶吧。
总结：SOLID都和开关原则有关，是开关原则的体现。