4 个重要的软件设计原则及快速解释

依赖倒置

DRY（不要重复自己）

单一职责原则

告诉我们您希望简化的其他编程原则，或者告诉我们如何在这 4 个原则上做得更好（如果您仍然无法理解）

您发现还有其他编程设计模式难以理解吗？

对前端开发感兴趣？我们刚刚发布了免费速成课程（真的免费——无需升级，无任何隐藏费用）

了解编程中的设计模式可以为我们提供在许多不同环境中工作的工具，以提高代码的整体质量。

我们认为您在网上找到的解释过于复杂，因此我们（副业）致力于简化这些解释，以便每个人都能理解。今天我们来看一下其中的五个：

YAGNI（你不需要它）

现实世界的例子
想象一对夫妇——杰克和吉尔。

杰克一直生活在对世界末日和黑死病复发的恐惧之中。

他建了一个末日避难所，走到哪儿都穿着防生化服。他有一种“安全第一”的心态。

吉尔为杰克以及他对那些可能永远不会发生的事情的过度补偿感到沮丧。吉尔理解为未来做准备的必要性，但不应该为那些不太可能带来任何有价值回报的事情投入大量精力。

用编程术语来说
，好吧，这的确是一个极端的例子。在商业和个人项目领域，情况会更加微妙，所以你需要根据你正在从事的业务或项目来思考 YAGNI。

也就是说，如果你在一家资金充足的初创公司工作，并且有 3 年计划，并且对公司的发展方向相当确定，那么最好提前几个月做好预防措施。

如果这是一个个人项目，您可能不需要所有那些花哨的东西 - 最好专注于核心功能。

这里的推理可以反过来——优秀的 CTO 和高级开发人员通常都能发现这一点。这实际上取决于业务/项目的需求。

用模块化的方式编写代码也很好，这样你就不用被迫编写预先需求的功能了。如果你不得不为几个月后即将发生的事情编写预防性代码，那么这可能会产生“代码异味”。

依赖倒置

现实世界示例
假设有两家银行 - “银行 A”和“银行 B”

为了从 A 银行取款，你需要将卡插入 ATM 机，输入密码，然后会出现一个登录到 MySQL 服务器的终端/命令行界面。在这里，你需要编写一个更新查询来从你的银行余额中扣除资金——然后机器就会把钱给你。

为了从 B 银行取款，您需要将卡插入 ATM，输入密码，在密码键盘上输入您想要的金额，然后机器就会将钱给您。

第一个违反了这个原则，第二个没有（你可能已经猜到了......）

在编程术语中，
要理解的关键是您的类和函数不应该知道有关它们的依赖关系的任何信息。

这会导致所谓的“紧密耦合”，如果你想要将你的依赖项换成不同的依赖项，这会变得很麻烦，你必须有效地重写使用它的所有内容。

就像现实世界中的例子一样，如果银行 A 决定从 MySQL 转向 MongoDB，那么其所有客户现在都必须学习如何编写 Mongo 查询。

在编程世界中，如果您的“ShopModel”只能与“MySQLConnection”一起工作，如果您突然切换到基于 Mongo 的架构，那么使用该连接的其他 40 个模型现在需要更改为“MongoConnection”

相反，他们应该使用“DBConnection”接口（定义所有数据库连接的样子），并且某种类型的容器应该提供该接口的当前实例。这样以后修改起来就容易多了。

DRY（不要重复自己）

现实世界示例
假设有两个社交媒体代理机构 - 代理机构 A 和代理机构 B

当 A 机构在团队中聘请新的社交媒体经理时，该经理会通过观察团队中的其他经理并复制他们的流程来学习社交媒体策略。

如果A公司的老板想改变流程，他会和每个经理坐下来，把变化告知他们。有时他会忘记通知一两位经理，这意味着他们正在执行一些冗余的流程。

当机构 B 在团队中聘请一位新的社交媒体经理时，该经理通过阅读每个人都可以访问的一份 Google 文档来学习。

如果 B 机构的老板想要更改流程，他会在 Google 文档中进行更改，并在 Slack 频道中标记所有人以查看更改。这意味着他一次性更新了所有人的信息。

机构 A 违反了 DRY，而机构 B 却遵守了 DRY。

用编程术语来说
，如果您发现自己编写的代码一遍又一遍地执行相同的操作，您可能希望将该功能放入应用程序中可重复使用的类、方法或函数中。

情况并非总是如此，对于何时应该、何时不应该这样做，人们的看法也褒贬不一。但作为一名新开发人员，开始思考哪些地方可以实现代码复用确实很有益处。你会逐渐理解其中的细微差别，尤其是在与其他经验丰富的开发人员合作时。

单一职责原则

现实世界示例
Phil 是一名平面设计师。他的老板希望他同时管理社交媒体账户、在 Phil 打高尔夫球时帮忙照看狗狗、帮忙整理货架以及挤牛奶。

菲尔的责任太多了；你可能会说他违反了单一责任原则。

但这是他老板的错，他应该为每项职责聘请专人。这才是遵循单一职责原则。

在编程术语中，
无论您是功能性程序员还是 OOP 程序员，您都将在应用程序中构建“功能片段” - 无论是函数、类还是任何其他执行符号。

如果您尝试描述您的一小段代码所承担的职责，并且您提出超过 1-2 点，那么您可能违反了 SRP。

仅供参考：这条线会随着经验的积累而变得更加清晰，但一种简化学习的方法是查看主要的开源存储库，并尝试解释您认为每个文件/类等的职责是什么，然后您就会开始发现人们开始分离事物的模式。

告诉我们您希望简化的其他编程原则，或者告诉我们如何在这 4 个原则上做得更好（如果您仍然无法理解）

我们确实想尝试帮助每个人都能了解这些“中级开发人员原则”——因为如果有人能提供书面解释，他们就不必是中级开发人员。

• 您还发现哪些原则难以理解？
• 我们在这篇文章中对哪些内容解释得不够清楚？

感谢您的反馈并帮助我们策划您认为有用的内容！

您发现还有其他编程设计模式难以理解吗？

请在下方讨论区留言告诉我们，这是我们“傻瓜编程原则”系列的第一篇文章，我们希望尽可能地让初学者能够理解这些原则。因为这能让我们写出更好的代码！

对前端开发感兴趣？我们刚刚发布了免费速成课程（真的免费——无需升级，无任何隐藏费用）

我们花了几个月的时间进行专业设计，并制作了4 小时 20 分钟的视频内容，为您带来免费速成课程，向您展示如何编写这个作品集网站的代码（我们不断鼓励您根据自己的风格进行定制）

如果您对此感兴趣，并且想要了解有关 HTML、CSS、SCSS、Bootstrap 4、Git、GitHub Pages 以及 JavaScript 和 jQuery 的更多信息，您可以从此处的链接免费注册。