我以为只要将逻辑理清就能模仿上帝。
现在，至少现在，在游戏公司写代码了，什么音频程序，自欺欺人说不只是程序员，其实本质也就是个码农啦。被人问起来还得解释老半天，下次直接说是程序员就好了。喔不对，可能下次就不是程序员了说不定因为太菜了就要被开了。哈哈。
老是写面向过程也是不行的了。但话说回来，老是写代码，写一辈子代码，也是不行的吧？
不太想写成很专业味的博客诶，是被迫开始接受、但学到一半感觉还挺有趣的知识。所以才有心情记在博客里吧。
我说啊，我是信息安全专业，自己从没有被教过正儿八经的软件开发思想和技巧，老师们看起来也是根本不在乎编程的优雅的。SOLID这些东西竟然是大型软件开发的基本功么，超出我这贫瘠的想象了，可能码农并没有那么不堪，其实也是很厉害的也说不定呢。
总之，言归正传了，曾经一直有一大疑惑：面向对象难道就是把面向过程拆散了然后写进不同类方法里的自欺欺人和多此一举么？
学也好，研究也好，这次看了SOLID的比较多，可能也就十多篇东西过后，对面向对象终于有了可能更好的认知了。
但是啊，没人有义务告诉我我的认知是否正确，如果你看见博文里有什么不妥，可以评论。请多指教吧。
先写下SOLID缩写各自对应的中文意思。
S：单一职责原则；
O：开放封闭原则；
L：里氏替换原则；
I：接口分离原则；
D：依赖倒置原则。
参考了的东西的链接，中英文都有。也按照这几个字母来分。
SOLID总体：https://insights.thoughtworks.cn/what-is-solid-principle/；https://blog.csdn.net/houzhizhen/article/details/79993880；https://blog.csdn.net/lan_liang/article/details/38662183；https://blog.csdn.net/lan_liang/article/details/38662253；https://blog.csdn.net/lan_liang/article/details/38704461；https://blog.csdn.net/bobo553443/article/details/79484385；
S：https://www.cnblogs.com/gaochundong/p/single_responsibility_principle.html；https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/；
O：https://www.cnblogs.com/gaochundong/p/open_closed_principle.html；
L：https://www.cnblogs.com/gaochundong/p/liskov_substitution_principle.html；https://blog.csdn.net/xingjiarong/article/details/50081857
I：https://www.cnblogs.com/gaochundong/p/interface_segregation_principle.html；
D：https://www.cnblogs.com/gaochundong/p/dependency_inversion_principle.html；https://zhuanlan.zhihu.com/p/92488185；https://blog.csdn.net/king123456man/article/details/81626127；https://blog.csdn.net/king123456man/article/details/81626127；
其中，我个人认为最有帮助的是这几篇链接：
如何通俗易懂地举例说明「面向对象」和「面向过程」有什么区别？ - 黄色潜水艇的回答 - 知乎 https://www.zhihu.com/question/27468564/answer/228157178
技术 01 - 聊聊编程原则（OOP，SOLID） - 姚钢强的文章 - 知乎 https://zhuanlan.zhihu.com/p/46830303
这幅图：
最有帮助的是这段话：
链接：https://www.zhihu.com/question/27468564/answer/228157178
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
下面就是我的记忆记录了，不一定完整，完整的都在上面的文档里，自己看吧。
按照上面那张图的顺序来。
依赖反转（Dependence Inversion Principle, DIP）
啊，每个说到这个都会写的一句是：
高层模块不应该依赖底层模块，两者都应依赖于抽象。抽象不应依赖细节，细节应该依赖于抽象。
这句话确实够抽象的。
反正，比较常见的一个点就是，如果A类的某个功能依赖于B类的对象实例，那么A类就依赖于B类了。
而进一步地，需要AB类共同完成的那个“高层”的决策/过程，也就依赖于这样的具体实现方式了。抽象依赖了细节。
所以，这种情况下，就得把A类中的B类实例的操作，给抽象化，变成和B类无关的某种东西。
C#里面，就可以用接口做到这一点。
所以，这个原则有时也被总结为：面向接口编程，而非面向实现编程。
说到底，因为接口本身就是用来抽象的。
再抄一段：
（睡觉啦，明天再学点再来更新…更给自己看）