有 SOLID 原则例外吗？答案

【问题标题】：Are there SOLID principle exceptions?有 SOLID 原则例外吗？
【发布时间】：2017-01-04 00:54:52
【问题描述】：

我尝试在我的项目类设计中应用 SOLID 原则。 SOLID 原则是否有任何例外？我们是否必须明确地应用这些原则。比如我准备了一个工厂类。

class XAdderFactory
{
    private Person _person;

    public bool PersonHasNoRecords
    {
        get
        {
            return string.IsNullOrEmpty(_person.HasXRecords);
        }
    }

    public XAdderFactory(Person person)
    {
        this._person = person;
        if (PersonHasNoRecords)
        {
            new XListMakerAFactory(person);
        }
        else
        {
            new XListMakerB(person);
        }
    }
}

此类从不符合 OCP。
将来可能需要新的类型列表生成器，我必须添加一个新的 else if 块。
我的设计不好吗？
还是有没有经常提及的 SOLID 原则的例外情况？
我不确定，但我的示例是否符合 OCP 的“战略关闭”？如果您有其他关于 SOLID 异常的示例，我认为这对设计师会有帮助。

【问题讨论】：

SOLID 是一种灵感。大师知道何时打破规则。
我发现对 SOLID tonymarston.co.uk/php-mysql/not-so-solid-oo-principles.html 的批评。有人同意他的观点吗？

标签： oop design-patterns architecture solid-principles

【解决方案1】：

Open-Closed 原则是重要且有用的，但不应盲目地将其应用于所有类和所有模块。在某些情况下，创建支持可扩展性的抽象是不值得的，因为不需要扩展。在其他情况下，我们可以预计需求会发生变化，但我们不确定会发生什么样的变化，或者我们不确定其他需求，所以我们更愿意推迟决定，并从更简单的模块开始不尊重 OCP 的实现。

【讨论】：

感谢您的回答。我怀疑我的设计。我认为您的意思是使用更简单的模块，必须在第一阶段考虑 SRP。对吗？SRP 是否有任何例外，或者我们应该申请盲目的 SRP？
每条规则都有例外，但我同意我们应该处处坚持 SRP。我不会说我们应该盲目地应用它，因为它确实需要思考，因为“责任”这个词没有很好的定义。

【解决方案2】：

SOLID 原则只是指导方针。您可以使用或不使用这些原则来解决您的问题。

您的主要关注点应该是设计问题的解决方案，而不是使您的解决方案适合特定的设计模式或原则。

如果你真的认为你的类不应该被修改，那么只实现Open/Closed principle。一般来说，我认为修改现有工厂类以添加新类型没有任何问题。

以下三个原则对于设计解决方案非常有用

Interface_segregation_principle: 不应强迫任何客户端依赖它不使用的方法

不要在代码中使用胖接口，实现类必须覆盖未使用或不相关的方法。设计粒度接口并创建实现这些粒度接口的类。相关 SE 问题：

Interface Segregation Principle- Program to an interface

Dependency_inversion_principle：这个原则很好。您应该编程接口而不是实现。

Liskov_substitution_principle：如果您需要在运行时动态更改实现，请使用此原则。如果您的应用程序没有更改其实现，则您可能不需要此功能。

但Single_responsibility_principle 在所有五项原则中都值得商榷。模块可能具有单一职责，但设计一个迎合单一职责的类将导致成百上千个类。

【讨论】：

据我了解，SOLID 不是 OOP 的主要法则。我认为主要法则是 SOLID 的原因，例如可维护性、可重用性、不要重复自己等。当我们设计课程时，我们应该考虑这些标准一开始。
如何管理成百上千的班级？有什么要遵循的吗？我有关于这个问题的另一个问题，我无法得到任何答案。stackoverflow.com/questions/39162794/…
根据这个问题，我已经解释了何时使用哪个原则。我会尽快回答其他问题。你必须使用工厂方法、抽象工厂、策略和外观模式。

【解决方案3】：

SOLID 原则（或任何相关原则）是避免软件项目在实施和维护方面的潜在陷阱/威胁的指南。而只是盲目地遵循一个原则而不知道它的反映是根本行不通的。

作为您的示例，我将采用 OCP。 OCP 背后的关键概念是，如果您的项目 100% 符合 OCP，那么任何其他人（可能是外人，新成员）都可以在不查看当前代码而只需查看您的 api 文档（关于公开的方法）的情况下进行编码这真的让那个人的生活变得轻松。并且也不需要一次又一次地测试现有代码，因为现有代码不会发生任何修改。但确实在某些情况下我们必须打破 OCP。

例如：

一个新要求。（需要在现有类中实现），
错误修复
有限的框架支持（任何 MVC 框架）等。

而且在某些情况下，我们可能会在知道它不会造成伤害的情况下破坏 OCP。

关于原理，你可以有一个简单的类比。当您在路上行走时，作为行人需要遵循许多原则。

例如：

左侧行走。（这样你就可以看到来车）
仅在人行横道上通过（这样车辆可以清楚地看到您并停下来）。

尽可能地遵循它们肯定会让你安全。但是想象一下道路上数英里内没有车辆的情况，您还在寻找人行横道过马路吗？没有权利？你知道你是安全的，即使它不是人行横道并且你过马路。而如果出现左手边泥泞不堪，走不动路的情况，你还会按照原则去泥地吗？没有权利。你宁愿走右手边知道情况。

我认为您对原则有所了解。 :)

【讨论】：

【解决方案4】：

我想我发现编写代码时必须考虑的第一件事。它是单元测试。可靠的原则、设计模式等是有助于进行单元测试的工具。据我说，任何没有经验的程序员（如我）都必须申请单元测试无一例外。测试结果已经引导程序员走向更好的设计。

【讨论】：