免责声明：每个人都可以，但是我最糟糕的是什么？
SOLID是用于组织代码的一组原则。 实际上，他们声明了某些规则，可以帮助您节省彼此和他人的神经和时间。 否则他们可能无济于事。
让我们尝试掌握这些原理，而无需代码示例和SMS。
S-单一责任原则（SRP）
更改班级应该只有一个理由（“班级只有一个更改理由。” Robert C. Martin。）
想象一下，您的计算机上有五首喜欢的歌曲，几部电影和猫的照片。 您将所有这些都带入“我的文档”中，并从总体上享受生活。
然后，您可以下载更多电影，您喜欢的乐队的新专辑和十二只新猫。 在“我的文档”中，它变得有点不舒服，您将所有内容都安排给爸爸。
乐曲
电影
封条
然后，您可以无限制地连接速度，轻松搞定，下载所有包含您所喜欢的唱片的Simpsons系列唱片，然后将与朋友一起钓鱼的照片添加到猫的照片中。 爸爸开始分支。
乐曲
门
等待太阳
你好，我爱你.mp3
...
...
铑
阿古丁
录影带
电视节目
电影
私人工作室
相片
封条
垂钓
在该国偏爱
妓女
我们这里有什么？
- 音乐-仅对音乐负责。
- The Doors-仅负责The Doors播放的音乐
- 等待太阳-只对专辑《等待太阳》负责
- 你好，我爱你.mp3-只负责歌曲你好，我爱你
改变《大门》的原因可能是什么？ The Doors的歌曲只有一种（定性或定量）变化。 但是从“ / Video / TV Series /”中删除无聊的电视剧并不是这样的原因，就像将“ Music”重命名为“ Music”一样。
可以得出什么结论？
- SRP涉及分解（分为子文件夹）和连接性（“ Hello，I Love You.mp3”仅与“ Waiting for Sun”相关联，她并不关心“ ../Series”的更改。另一方面，所有歌曲“门”位于其中，并且不应位于“猫”文件夹中）。
- 更改原因的抽象级别不应高于要更改的实体的抽象级别。 在任何情况下，将“ Alla Pugacheva”子文件夹添加到“ Music”都不能成为“ Waiting for Sun”更改的原因。
- 无需提出荒谬的论点。 如果您拥有三首歌曲，一台vidos和五张猫的图片，那么它们在一堆中看起来会很棒-将它们放到文件夹中只会使一切变得混乱。 像“门中最好的”专辑一样，您不应该按年份将其分为几个子文件夹，每个子文件夹都只有一首歌。
O-开闭原理或OCP
软件实体（类，模块，功能等）应打开以进行扩展，但应关闭以进行修改。”伯特兰·迈耶（Bertrand Meyer）
当您无限连接速度时，让我们回到历史的一步。 假设您首先收集了有关电影公司Private的管道工的各种电影，并且由于它们都是关于管道工的，因此创建了文件夹“ / Video / About Plumbers /”。
一段时间后，您从该工作室下载了更多电影，但是已经发送了披萨。 此外，您的新女孩给您写了一条短信“我下载了电影“ Afonya”，并将其保存在文件夹/视频/关于管道工/可以吗？”。 一切似乎都是正确的-关于管道，但有细微差别。
在这里您可以清楚地知道，不修改文件夹（类）的现有结构就无法更改功能，这显然违反了OCP原则。
在这种情况下必须怎么做？ 最初设计系统非常简单，因此新功能不需要更改旧代码。 即 不要对文件夹“ ../Pro plumbers /”进行硬编码，希望将来只会有它们，但是将抽象级别提高到“ ../Studio Private /”，并冷静地喂她的水管工和披萨送货员等。 -其他...
然后为Afoni创建一个新类，例如“ ../Mosfilm/”，扩展该类“ / Video /”
结论：
- 提前考虑一下如果出现其他有关管道工的电影，你会怎么做。 也许您应该立即执行此操作，以免日后重做？
- 该原理主要是关于抽象类（“ ../Studio Private /”）。
L-芭芭拉·李斯科夫的替代原理或LSP
程序中的对象必须可以用其子类型的实例替换，而无需更改程序的正确执行。
好吧，这很简单。
为了进行说明，我们来谈谈甜蜜和幸福，尤其是文件夹“ / Photo / Seals /”。
我们爱猫，并且收集了很多照片。
相片
封条
红发女郎
条状
湿的
黑色的
玛努拉 碰巧我们甚至直接在整个根文件夹中启动幻灯片并欣赏它。 因此，在一个好时刻，当您几乎达到必杀技时，屏幕将显示：
无法显示文件“ / Boots.fb2中的/照片/印章/书籍/猫”
后来发现，您的朋友决定提高可爱程度，并严重违反了LSP，并继承了带有新“ Book”子文件夹的“ Seals”，因为“ Book”的子类不能代替基类“ Photo”使用。
结论：
- 名称令人恐惧，定义复杂，但是原理本身简单直观。
- 如果您的方法希望“照片”进入，那么您从“照片”中继承的哪个继承人都无关紧要：“ Manuli”，“ Redheads”或“ Wet”，但是如果出现“ Books”，则预计他会tea茶。
I-接口隔离原理或ISP
客户不应依赖他们不使用的方法。
在这里用文件夹和文件很难解释，但是我会尽力-不要严格地判断是否有些紧张。
您已经厌倦了标准的音乐播放器，并决定下载一个新的流行和炒作。 他甚至知道如何显示音乐专辑的封面和显示已演唱歌曲的字幕。 但是麻烦是，如果“ cover.jpg”和“ subtitles.txt”文件不在相册文件夹中，则播放器将崩溃并显示错误。 现在，诅咒世界上的所有事物，您就开始在具有相册的所有子文件夹中创建这些存根文件。
也就是说，得出不正确的类比，我们有义务Music类及其所有继承人实现AudioCoverSubtitles接口。 同时，此接口仅完全实现“等待太阳”专辑，“ The Best of the Doors”专辑仅实现“音频+封面”部分，其余仅实现“音频”。
这使我们想到了一个合理的想法，那就是将厚的AudioCoverSubtitles界面分为三个小型Audio，Cover和Subtitles，并仅在真正需要它们的地方使用它们。
结论：
- 突然之间，ISP即将实现接口分离。
- 如果您的界面强迫您创建存根方法，那么这是一个错误的界面，您应该使用剪刀对其进行检查。
D-依赖反转原理或DIP
上级模块不应依赖于下级模块。 两种模块都应依赖抽象。
抽象不应依赖细节。 细节应取决于抽象。
“门”模块不应取决于其包含的音频文件类型是.mp3，.flac或.wav。
Doors模块（其Waiting the Sun子模块）（以及其他所有模块）取决于Music的顶级抽象，后者决定了它们的实现（它们内部有音乐）。
假设我们决定根据压缩原理（“有损”和“无损”）分离音乐的存储。 这些是对抽象“音乐”的依赖所结合的细节-在其中，最终仍然必须有音乐。 此外，抽象“音乐”本身并不依赖于这些细节。 她不在乎音乐是在那里丢失还是没有丢失-就像音乐一样，它仍然如此。
结论：
- DIP-就是这样，具体应该取决于一般，而不是相反。
- DIP是“向抽象之神提供更多抽象！”
- DIP还涉及因果关系，以及对以下问题的正确答案：“树枝因风吹动而摆动，或者风速因树枝吹动而摆动”
谢谢，祝您周末愉快！