SOLID原则编程指南

SOLID原则是建立一个组件间低耦合度的系统的有力工具。 首先对这些原则做一个简单的回顾： SRP：单一责任原则 OCP：开放封闭原则 Liskov替代原则 接口隔离 依赖性反转

if/else/switch语句的泛滥是软件系统中的常见问题。它们在许多地方被复制的事实是有问题的。几天前，有人在推特上发了一个问题，询问以下哪个PHP片段更好，或者是否有更好的方法。

作者背景：从1981年左右到2014年退休，我一直从事软件工程或相关学科的研究。从1984年到2014年，我的所有研究都涉及与英国和整个欧洲的工业界合作。我有幸与来自不同行业和国家的许多人一起工作，我从这些经历中学到了很多东西。

著名敏捷专家Allen Holub认为：编写“快速而肮脏”的废代码可以使您更快地推向市场是一个神话。至少我从未见过这项工作。最快的上市方式是编写高质量的，经过良好测试的代码。马丁福勒称这种“快而脏”代码是鲁莽导致的债务reckless debt.什么是足够好、高质量的代码？他认为TD

我相信这是因为我们将讨论创建产品时最普遍的问题之一：过度设计。在我看来，与缺乏良好的开发实践相比，过度设计杀死了更多的产品。在详细介绍之前，让我先和您谈谈我的背景。在成为产品经理之前，我是一名工程师。事实上，我的正规培训是计算机科学。虽然在我的职业生涯中，我一直更接近业务而不是自己编

SOLID 原则基本上构成了构建面向对象、松散耦合、健壮、可维护和易于理解的应用程序的基本准则。最常被问到的面试问题之一，让我们来看看： 单一职责：一个类应该有且只有一个职责。我们应该仅仅为了一个目的而编写、更改或维护一个类，这给我们

可汗学院正在完成一个巨大的项目，将我们的后端从Python迁移到Go。虽然这个项目的主要目标是迁移到一个过时的平台上，但我们看到了改进我们代码的机会，而不仅仅是直接移植。 我们想改进的一件大事是我们的Python代码库中的隐性依赖关系。访问当前请求

如何看待开闭原则（OCP）？ 有些人不认同OCP，他们认为我们应该专注于编写简单的代码。 我同意这一点，但是我没有看到简单性和OCP是如何不兼容的。有两个初步要点：OCP的目标不是编写我们再也不会修改的关闭代码，否则将导致过度设计和前端大设计（BDUF）。 我们将用无

KISS（保持简单愚蠢）： 即使解决方案看起来很愚蠢，简单的解决方案也比复杂的解决方案好。 当解决方案使用较少的继承，较少的多态性，较少的类等时，解决方案会更好。 更简单的解决方案更易于维护，即检测和纠正缺陷更加有效。

YAGNI 是You Ain't Gonna Need It（你不会需要它）的简写，是极限编程的关键原则。YAGNI意思非常简单：仅在您真正需要它们时才去做，而不是在您认为或预见将来可能需要它们时就提前做了！您可以将YAGNI视为即时制造的拥护者。在这种情况下，制造业正在编写

SOLID原则是美国软件工程师和讲师罗伯特·C·马丁 (Robert C Martin) 提倡的众多原则的一个子集，他被称为“鲍勃大叔”。在本文中，我将讨论S {O} LID原则之一，即开闭原则（OCP）。我会使用 C# 来演示代码，但 OCP 与语言无关。OCP的官方定义是

学习领域驱动设计DDD、软件架构、设计模式、最佳实践的包含Javascript案例 该项目的主要重点是就如何设计领域驱动六边形

作为专业或有抱负的软件工程师，我们通常的任务是将业务规则转化为计算机可以理解的东西。我们使用类对问题域进行建模，并编写业务逻辑以反映存在于代码库之外的现实世界规则。当这些业务规则在现实世界中发生变化时，它们也必须在代表它们的代码中发生变化，这就是我们领域真正复杂的地方。 

Liskov替换原则是SOLID的一部分，该缩写缩写总共捆绑了5条设计原则。它通常与干净的代码相关联。但是到底是什么，对您来说重要吗，您甚至应该关心吗？ 它是什么？如果S是T的子类型，则可以用类型S的对象替换类型

规则引擎模式是什么？哪些地方需要用到？实现规则引擎模式，SOLID原则是一个很好的选择。业务规则的项目是通过if/else函数来实现的，但是在我们的许多业务规则中，我们需要编写更规则的代码，if/else使事情变得更复杂。另一方面，当定义了一组新的规则，而不是定义一个

以下是 Clean Code 关于编写可读函数的建议的摘要。这个建议是针对用 OOP 语言编写的函数，尽管许多概念会延续到其他编程范式。 原则 1 - 小！ 你的大部分功能应该少于15行，而且几乎不应该超过20行。 <