后端开发教程 - Java、Spring Boot 实战 - msg200.com
揭开 10 个编码原则和首字母缩略词的神秘面纱！
吻
干燥
亚格尼
拍击
SRP
开路保护协议
语言服务提供商
互联网服务提供商
蘸
坚硬的
唯一的原则
这篇文章取自我的博客，因此请务必查看以获取更多最新内容。
说到首字母缩略词，编程行业可谓琳琅满目。随便哪个都行——这些既有趣又有意义的缩写词真是数不胜数。如果你才刚入门，看到这些缩写从左到右冒出来可能会有点不知所措。尤其是在你完全不知道它们是什么意思的情况下！总之，如果是这样，这里有一篇博文推荐给你！
在本文中，我们将探讨 10 条不同的编码原则，它们都带有一些相当神秘的缩写。有些缩写广为人知，而有些则鲜为人知。理解这些缩写并将其应用于代码的难度也各不相同。话虽如此，我将尝试详细解释每个术语背后的整个理论。至于有趣的部分——它们的实现——则留给你自己去探索。
吻
让我们从一些比较流行的原则开始。“保持简单”（KISS）是最著名的原则之一。它的含义也相当清晰，但非常广泛。
基本上，这条原则要求你应该保持代码非常简单，这是毋庸置疑的。代码越简单，你和其他维护它的人就越容易理解。简单性主要指的是不使用诸如此类的技巧，也不要把不必要的事情弄得太复杂。
违反此规则的基本示例包括编写一个单独的函数仅用于执行加法运算，或者使用按位运算符（右移 >>1）将整数除以 2。后者的性能无疑比其通常的对应项（/2）更高，但却大大降低了代码的“可理解性”。这样做，你就犯了所谓的“聪明编码”和“过度优化”的错误。这两种情况都不利于代码的长期“健康”。
干燥
“不要重复自己”（DRY）原则的本质与 KISS 非常相似。它非常简单，但含义却十分广泛。
很多程序员都会复制粘贴和重复自己编写的代码片段。这样做本身并没有什么错。每个人有时都需要快速检查某些内容（例如预期行为或其他内容），以便日后确定是否值得费力地编写正确的代码。但将这样的代码交付到生产环境绝对是不可接受的。
DRY 原则提醒我们，代码中的每个重复行为都可以而且应该被提取出来（例如在函数内），以便以后重用。代码库中存在两段相同的代码片段并不好。这通常会导致代码不同步和其他 bug，更不用说程序大小的增加了。
资源：
亚格尼
YAGNI 实际上是这个列表中最长的缩写。“你不需要它”（YAGNI）这个原则可能会与一些程序员的观点相冲突。
为未来做好准备通常是件好事，但在编程领域却并非如此。留下任何只为未来扩展而生的代码都是不妥的。但如果这与你的理念相悖，我们可以进一步讨论。
编码项目并非有明确结局的事情。除非创建者放弃这个想法（并且不将其交给其他人），否则项目实际上终将结束。但除此之外，代码几乎永远不会达到“足够好”的程度。总有改进的空间。展望未来，思考一下你希望你的代码是什么样子，这固然很好。但在生产环境中，除非是被巧妙利用或必需的功能，否则留下“扩展点”（旨在轻松实现新功能的位置）是不可取的。这会增加不必要的复杂性，并增加代码库的大小。仔细想想，这甚至与之前讨论过的 KISS 原则相冲突。
资源：
拍击
你猜怎么着！你不仅可以 KISS 或 DRY 代码，还可以 SLAP 代码！单层抽象原则(SLAP) 规定了你应该如何组织代码（具体到函数），以保持代码的可维护性。
长而复杂的函数让人难以忍受。它们难以理解，难以测试，而且通常需要滚动才能查看所有内容！如果你遇到这种令人厌恶的情况，应该立即将其重构为几个较小的函数！记住：
函数应该只做一件事，并且要做好。——罗伯特·马丁
但是，你究竟应该如何组织这些小函数呢？它们应该做什么呢？随着你编程经验的积累，你会开始感觉到某些事情应该放在哪里，而 SLAP 会帮助你。
你的函数应该只做一件事，或者，考虑到 SLAP，应该只有一个抽象层级。基本上，例如，一个读取用户输入的函数不应该同时处理它。相反，它会使用一个单独的函数，这个函数位于另一个较低的抽象层级。函数越通用，它使用的其他函数越多，它在抽象层级中的位置就越高。
资源：
SRP
单一职责原则(SRP) 与 SLAP 有点类似，但更侧重于面向对象编程(OOP)。它建议你组织你的对象和类（以及函数和方法），使它们每个只承担一项职责。
当对象和类反映更逼真的对象时，它们的职责很容易组织。然而，当我们处理名称中带有“控制器”或“服务”等字样的实体时，情况就开始变得复杂。这些高级单元很难组织，因为理论上，你可以把几乎所有东西都放进去，然后就完事了。在这种情况下，此类实体的职责数量会急剧增加，使整个代码变得越来越难以理解。
如何解决这个问题？假设我们的控制器负责控制一台计算机。它需要控制和存储CPU温度、风扇转速、磁盘空间、外部设备等等。需要注意的是，这不仅意味着属性，还意味着我们要处理的方法。与其将所有东西都直接放在一个类中，不如将它们拆分成多个类？这样我们就有了DevicesController，DiskSpaceController等等。然后，我们可以用所有这些类来组成一个高级Controller类，这样维护起来就容易多了。当然，实际上，这样的代码需要更精细的组织，但我希望你能理解我的意思。
开路保护协议
我们在讨论 YAGNI 时已经讨论过代码的可扩展性。开放封闭原则(OCP) 与前一条规则有些关联，但视角不同。
OCP 要求你的代码对新的、未来的添加保持开放，而无需修改已编写的代码。它更关注代码的整体架构，而不是代码本身。
OCP 和 YAGNI 冲突吗？毕竟，我们讨论代码的未来是从两个不同的角度出发的，对吧？答案是否定的。正如我之前所说，YAGNI 会阻止你添加当前不使用的代码。而 OCP 则更深入地探究你的代码架构，从核心层面确保其面向未来。你不应该编写任何当前不使用的代码，而应该以易于扩展的方式设计整个代码库。
使您的“核心”可扩展，在此基础上构建当前的功能，并拥有良好的、面向未来的架构，而无需编写任何死代码。
语言服务提供商
里氏替换原则(LSP) 以其创建者Barbara Liskov的名字命名，是一种 OOP 原则，与类、接口、类型和子类型相关。
这条规则本身非常简单且合乎逻辑，但一开始可能比较难理解。它表明任何子类型都必须可以替换其基类型。我认为需要一个例子来更好地说明这一点。
让我们以臭名昭著的矩形和正方形问题为例，这个问题通常被用来说明这一原理。我们有一个Rectangle类（基类型），它具有和等属性width，height以及设置它们并计算面积的方法。通过继承，我们创建一个Square类（子类型），它有一个额外的方法来同时设置width和height计算面积（例如setSide）。
如果我们单独使用这些类，什么也不会发生。但是，由于该类Square是 Rectangle 类的子类型，因此可以将其赋值给接受Rectangles 的变量。这可能会导致错误的setHeight和setWidth调用，导致我们的Square实例具有不正确的尺寸并计算错误面积（或者如果进行了检查，则会抛出错误）。
Square我们可以通过直接在类的setHeight/setWidth方法中检查实体是否属于子类型来轻松解决这个问题Rectangle。遗憾的是，在这个过程中，我们会承认子类型的存在Square，从而破坏 LSP。您也可以覆盖setHeight/setWidth方法，但现在它们与原始类不兼容，再次导致 LSP 破坏。
互联网服务提供商
接口隔离原则(ISP) 是另一个关于如何组织代码的原则。由于它主要关注接口和静态类型编程语言，因此使用 JavaScript 等编程语言的人不会经常使用它。然而，ISP 带来的知识仍然可以用来以其他方式改进你的代码。
接口是一种处理数据形式的方式，而不是数据本身。正确地编写和组织接口可以极大地提高代码的可维护性，而不会造成太多性能损失。
这就是 ISP 的精髓所在——使用接口隔离代码，同时保持接口本身的井然有序。以类继承为例。也许您不关心基类中的某些方法或属性，想要“跳过”它们？一个简单的接口就能帮您做到这一点！在编译型和静态类型语言中，它还能带来一些优势，例如作用域更清晰、编译时间更快（当父类的属性（接口指定的属性除外）发生变化时，子类无需重新编译）。
蘸
与 OCP 类似，依赖倒置原则(DIP) 也指代更通用的代码架构。事实上，它是代码架构设计中最重要的原则之一。
DIP 有点复杂，但你只需要理解两点就能正确遵循它。首先，你的代码应该以某种方式编写，其中实现细节（例如用户界面 (UI)、数据库）应该依赖于主逻辑（即业务规则），而不是其他方式。
其次，所有这些依赖关系都不应该直接存在。你应该通过接口等方式抽象它们，这样你的主逻辑就能处理你交给它的任何依赖，只需要实现一些简单的“桥接”代码即可。
坚硬的
前面讨论过的五项原则——SRP、OCP、LSP、ISP、DIP——共同构成了SOLID——一套指导你如何编写优秀的面向对象（但不止于此）代码的原则，由Robert C. Martin创建。我希望通过这篇博文的描述，能够为这个充满原则的编程世界的初学者提供“足够合乎逻辑”的解释。但是，如果你对这个主题感兴趣，我建议你搜索一下网页或访问链接中的资源来了解更多信息。
资源：
唯一的原则
最后，我们来看看唯一原则（TOP）。好吧，我只是开个玩笑！但实际上，本文讨论的所有编码原则（甚至所有其他原则）都只有一个目标——帮助你编写优秀、可维护的代码。这是它们的首要任务。虽然了解这些原则确实有帮助，但只有你才能掌控你的代码以及它的外观。
希望您喜欢这篇博文，并从中学习到新知识！如果喜欢，请分享，并在Twitter、Facebook上关注我，或者访问我的个人博客了解更多信息！另外，如果您感兴趣，我还有一个YouTube 频道。一如既往，非常感谢您阅读这篇文章，祝您有美好的一天！
文章来源：https://dev.to/areknawo/10-coding-principles-and-acronyms-demystified-3ha4