SOLID原则是否真的很稳固？

这个首字母缩写代表的devise模式是单一责任原则。这是一个报价：

单一职责原则规定，每一个对象都应该有一个单一的责任，这个责任应该完全被这个阶级所包围。

直到我们开始编码之前，这很简单明了。假设我们有一个明确的单一责任类。要序列化类实例，我们需要为该类添加特殊的atrributes。所以，现在这个class还有另一个责任。这不违反SRP吗？

我们来看另一个例子 – 一个接口实现。当我们实现一个接口时，我们简单地添加其他职责，比如说处理其资源或比较它的实例或其他。

所以我的问题。是否可以严格遵守SRP？如何做呢？

正如你将来会发现的那样，软件开发中最为人所知的原则中没有一个能够被100％遵循。

编程往往是做出妥协 – 抽象的纯粹与代码大小与速度与效率。

你只需要学会find适当的平衡：不要让你的应用程序陷入混乱的深渊，但不要把自己的手与多个抽象层绑在一起。

我不认为序列化或一次性是多重责任。

那么我想首先要注意的是，这些只是一个很好的软件工程原理 – 你也必须应用判断。所以从这个意义上说 – 不，他们不是固体（！）

我认为你提出的问题提出了一个关键问题 – 你如何定义class级应该具备的单一责任？

定义一个责任时不要过分地注意细节是很重要的 – 仅仅因为一个类在代码中做了很多事情并不意味着它有很多的响应。

不过，请尽pipe坚持下去。虽然在所有情况下都可能无法应用，但它比在代码中使用单一的“上帝对象”（反模式）更好。

如果你有这些问题，我会build议阅读以下内容：

重构 – 马丁·福勒（Martin Fowler）：虽然很明显是重构，但是这本书对于展示如何将问题分解成逻辑部分或可重复性（SRP的关键）也非常有帮助。这本书也涉及到其他原则 – 但是它比你以前看到的要less得多。
清洁法典 – 罗伯特·马丁：谁最好是比固体原则最伟大的代表人物。认真地说，我发现这是一本真正有用的软件工艺方面的书 – 不仅仅是SOLID原则。像福勒的书一样，这本书是在各个层面上体现的，所以我会推荐给任何人。

为了更好地理解SOLID原则，您必须了解他们解决的问题：

面向对象的程序devise从结构化/程序化编程发展而来 – 它增加了一个新的组织系统（类，等）以及行为（多态，inheritance，组合）。这意味着面向对象不是从结构化/程序性分离的，而是一个进展，开发人员可以做非常程序化的OO，如果他们想要的话。

所以… SOLID来回答这个问题：“我真的在做OO，还是我只是在使用程序对象？如果遵循这5条原则，就意味着你离光谱的OO很远。不符合这些规则并不意味着你没有做OO，而是意味着更多的结构/程序OO。

这里有一个合理的关注点，因为这些交叉关注点（序列化，日志logging，数据绑定通知等）最终将实现添加到多个只支持其他子系统的类中。这个实施必须经过testing，所以class级肯定负有额外的责任。

面向方面编程是尝试解决此问题的一种方法。 C＃中的一个很好的例子就是序列化，对于不同types的序列化，有很多不同的属性。这里的想法是，类不应该实现执行序列化的代码，而是声明如何序列化。元数据是一个非常自然的地方，它包含对其他子系统很重要的细节，但与类的可testing实现无关。

关于devise原则要记住的事情总是有例外，而且你不会总是发现你的场景/实现与100％的给定原则相匹配。

也就是说，给属性添加属性并不是真的为类添加任何function或行为，假设您的序列化/反序列化代码在其他类中。你只是添加关于你的class级结构的信息，所以这似乎不是违反了原则。

我认为如果一个类没有模糊一个类的主要职责：序列化，日志logging，exception处理，事务处理等，就可以做许多次要的，常见的任务。

根据您的业务/应用程序逻辑，您class级中的哪些任务构成了实际的责任，什么是pipe道代码。

那么，如果不是devise一个“吠叫”，“睡眠”和“吃”方法的“狗”类，我必须devise“动物窝”，“动物窝”，“动物窝”等类。为什么？这是如何使我的代码更好？我该如何简单地执行这样一个事实，即我的狗不会睡觉，如果没有吃东西，就会整夜吠叫呢？

“把小class分成小class”是一个很好的实践build议，但“每一个对象都应该有一个单一的责任”是一个绝对的面向对象教条式的废话。

想象一下.NET框架是用SRP编写的。而不是40000class，你会有数百万。

广义SRP（“广义”是这里的重要词）只是一个犯罪恕我直言。你不能将软件开发减less到5个书本原则。

通过改变“单一责任”的定义 – 固体原理是相当stream动的，并且（像其他首字母缩略词的缩写）并不意味着它们的含义。

他们可以作为一个清单或备忘单，但不是完整的指导方针，当然不是学习材料。

SOLID代表：

当我们谈论OOP时，这些就是我们所说的标准。但是，这些原则在软件开发中都不能完美实现。