软件开发的 20 条基本原则：LoD、SoC、SOLID 等

Introduction 介绍

Software design principles are the foundation of software development. As a software engineer, you can find them in your work tools, languages, frameworks, paradigms, and patterns. They are the core pillars of “good” and “readable” code. Once you understand them, you can see them everywhere.
软件设计原则是软件开发的基础。作为一名软件工程师，您可以在您的工作工具、语言、框架、范例和模式中找到它们。它们是“好”和“可读”代码的核心支柱。一旦你了解了它们，你就可以在任何地方看到它们。

The skill of seeing and applying them is what distinguishes a good engineer from a bad one. No one framework or tool can improve your quality of writing good code without understanding the fundamentals; moreover, without them, you become a hostage of that tool.
观察和应用它们的技能是区分好工程师和坏工程师的关键。如果不了解基础知识，任何一种框架或工具都无法提高您编写优秀代码的质量；此外，如果没有它们，您就会成为该工具的人质。

This article isn’t a reference guide but rather my try to systemize a list of core principles that need to be refreshed from time to time.
本文不是参考指南，而是我尝试将需要不时刷新的核心原则列表系统化的尝试。

Abstraction 抽象

Abstraction is one of the most significant principles in general. To abstract something means to focus on the important part while neglecting other details. Abstraction can be interpreted in two main ways: as a process of generalization and as the result of this generalization itself.
一般来说，抽象是最重要的原则之一。抽象意味着关注重要部分而忽略其他细节。抽象可以用两种主要方式解释：作为概括的过程和作为概括本身的结果。

In software development, it often comes paired with encapsulation, a method used to hide the implementation of the abstracted parts. You can observe abstraction in various forms. For example, when you define a type, you abstract yourself from the memory representation of a variable. Similarly, when you abstract an interface or the signature of a function, you focus on what’s important: the contract to work with. When designing a class, you select only the relevant attributes for your domain and the specific business use cases. There are tons of other examples, but
在软件开发中，它通常与封装相结合，封装是一种用于隐藏抽象部分的实现的方法。您可以观察各种形式的抽象。例如，当您定义类型时，您将自己从变量的内存表示中抽象出来。同样，当您抽象接口或函数签名时，您会关注重要的事情：要使用的契约。设计类时，您只需选择与您的领域和特定业务用例相关的属性。还有大量其他示例，但抽象的主要目的是您不需要了解实现的细节即可使用某些东西；因此，您可以更好地专注于对您来说至关重要的事情。the main purpose of abstraction is that you don’t need to know the details of implementation to work with something; therefore, you can better focus on what is essential for you.
在软件开发中，它通常与封装相结合，封装是一种用于隐藏抽象部分的实现的方法。您可以观察各种形式的抽象。例如，当您定义类型时，您将自己从变量的内存表示中抽象出来。同样，当您抽象接口或函数签名时，您会关注重要的事情：要使用的契约。设计类时，您只需选择与您的领域和特定业务用例相关的属性。还有大量其他示例，但抽象的主要目的是您不需要了解实现的细节即可使用某些东西；因此，您可以更好地专注于对您来说至关重要的事情。

This principle is not exclusive to application development. You, as a programmer, abstracted through language syntax from underlying actions with an operation system. The OS, in turn, abstract your language translater from underlying operations with a CPU, memory, NIC, and so on. The more you go deeper, the more you understand that this is just a matter of abstraction.
这一原则并不只适用于应用程序开发。作为一名程序员，您通过语言语法从操作系统的底层操作中进行抽象。反过来，操作系统将语言翻译器从 CPU、内存、NIC 等底层操作中抽象出来。你越深入，你就越明白这只是一个抽象的问题。

Source: Reddit 来源：Reddit

Encapsulate what varies 封装不同的内容

As you can see, abstraction can manifest itself in different forms — from data (implementation) abstraction to hierarchical. A general rule of thumb for using abstraction is the principle: “Encapsulate what varies.” Identify the potentially changeable part and declare a concrete interface for it. This way, even if the internal logic changes, the client will still have the same interaction.
正如您所看到的，抽象可以以不同的形式表现出来——从数据（实现）抽象到层次化。使用抽象的一般经验法则是以下原则：“封装变化的内容”。识别潜在可更改的部分并为其声明一个具体的接口。这样，即使内部逻辑发生变化，客户端仍然会有相同的交互。

Suppose you need to calculate a currency conversion. At the moment, you only have two currencies. You can come up with something like this:
假设您需要计算货币换算。目前，您只有两种货币。你可以想出这样的东西：

if (baseCurrency == "USD" and targetCurrency == "EUR") return amount * 0.90;
if (baseCurrency == "EUR" and targetCurrency == "USD") return amount * 1.90;

But another type of currency may be added in the future, which would require changes to the client code. Instead, it is better to abstract and encapsulate all the logic in a separate method and call that method from the client side when needed.
但将来可能会添加另一种货币，这需要更改客户端代码。相反，最好将所有逻辑抽象并封装在一个单独的方法中，并在需要时从客户端调用该方法。

function convertCurrency(amount, baseCurrency, targetCurrency) {
  if (baseCurrency == "USD" and targetCurrency == "EUR") return amount * 0.90;
  if (baseCurrency == "EUR" and targetCurrency == "USD") return amount * 1.90;
  if (baseCurrency == "USD" and targetCurrency == "UAH") return amount * 38.24;
  …
}

DRY 干燥

DRY (don’t repeat yourself), also known as DIE (duplication is evil), states that you shouldn’t duplicate information or knowledge across your code base.
DRY（不要重复自己），也称为 DIE（重复是邪恶的），指出您不应在代码库中重复信息或知识。

“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” — Andy Hunt and Dave Thomas, The Pragmatic Programmer.
“每条知识都必须在系统内有一个单一的、明确的、权威的表示”——安迪·亨特和戴夫·托马斯，务实的程序员。

The benefit of reducing code repetition is the simplicity of changing and maintaining. If you duplicate your logic in several places and then find a bug, you’re likely to forget to change it in one of the places, which will lead to different behavior for seemingly identical functionality. Instead, find a repetitive functionality, abstract it in the form of a procedure, class, etc., give it a meaningful name and use it where needed. This advocates a single point of change and minimizes the breaking of unrelated functionality.
减少代码重复的好处是易于更改和维护。如果您在多个位置重复逻辑，然后发现错误，您可能会忘记在其中一个位置更改它，这将导致看似相同的功能出现不同的行为。相反，找到一个重复的功能，以过程、类等的形式将其抽象，给它一个有意义的名称，并在需要的地方使用它。这提倡单点更改并最大限度地减少对不相关功能的破坏。

KISS 吻

The KISS (keep it simple, stupid) phrase was coined by aircraft engineer Kelly Johnson, who challenged his engineering team that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only specific tools.
KISS（保持简单，愚蠢）短语是由飞机工程师凯利·约翰逊创造的，他向他的工程团队提出挑战，要求他们设计的喷气式飞机必须由现场的普通机械师在战斗条件下仅使用特定工具即可修复。

The main idea behind it is to focus on the simplicity of a system, which increases understanding and reduces overengineering while using only the tools you really need.
其背后的主要思想是关注系统的简单性，这可以增加理解并减少过度设计，同时仅使用您真正需要的工具。

YAGNI 亚格尼

When you design a solution to the problem, you are thinking about two things: how to better adapt it to the current system and how to make it extensible for possible future requirements. In the second case, the desire to build a premature feature for the sake of better extensibility is usually wrong: even if you now think that this will reduce the cost of integration, the maintenance and debugging of such code may not be obvious and unnecessarily complicated. Thus, you violate the previous principle by increasing the redundant complexity of the solution to the current problem. Also, don’t forget here’s a good chance that your presumed functionality may not be needed in the future, and then you’re just wasting resources.
当您设计问题的解决方案时，您会考虑两件事：如何更好地使其适应当前系统以及如何使其可扩展以适应未来可能的需求。在第二种情况下，为了更好的可扩展性而构建过早的功能的愿望通常是错误的：即使您现在认为这会降低集成成本，但此类代码的维护和调试可能并不明显并且不必要地复杂。因此，您通过增加当前问题的解决方案的冗余复杂性来违反前面的原则。另外，不要忘记，很有可能将来可能不需要您假定的功能，那么您只是在浪费资源。

That’s is what YAGNI or “You aren’t gonna need it” all about. Don’t get it wrong; you should think about what will be with your solution in the future, but only add code when you actually need it.
这就是 YAGNI 或“你不需要它”的全部内容。别误会；您应该考虑您的解决方案将来的用途，但仅在实际需要时添加代码。

LoD 详细程度

The Law of Demeter (LoD), sometimes referred to as the principle of least knowledge, advises against talking to “strangers”. Because LoD is usually considered with OOP, a “stranger” in that context means any object not directly associated with the current one.
德米特法则 (LoD)，有时被称为最少知识原则，建议不要与“陌生人”交谈。由于 LoD 通常与 OOP 一起考虑，因此上下文中的“陌生人”意味着与当前对象不直接关联的任何对象。