Oop 有可靠的原则例外吗？

我试图在我的项目的课堂设计中运用坚实的原则。坚实的原则有例外吗？我们是否一定要应用这些原则呢。例如，我准备了一个工厂类

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块。
我的设计不好吗？
或者是否存在不经常提及的可靠原则的例外情况？
我不确定，但我的例子是否符合OCP的“战略关闭”？

---

如果你有其他关于实体异常的例子，我认为这对设计人员很有帮助。

开闭原则很重要，也很有用，但它不应该盲目地应用于所有类和所有模块。在某些情况下，创建支持可扩展性的抽象并不值得，因为不需要扩展。在其他情况下，我们可以预期需求会发生变化，但我们不确定预期会发生什么样的变化，或者我们不确定其他需求，因此我们宁愿推迟决策，从一个不尊重OCP的简单模块实现开始。

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

您的主要重点应该是设计问题的解决方案，而不是将您的解决方案与特定的设计模式或原则相适应

如果您真的认为不应该修改您的类，那么只需要实现。一般来说，在修改现有工厂类以添加新类型方面，我看不到任何问题

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

：不应强制任何客户端依赖其不使用的方法

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

这是个好原则。您应该编程到接口，而不是实现

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

但这在所有五项原则中都是有争议的。 模块可能有单一的职责，但设计一个满足单一职责的类将导致成百上千的类

坚实的原则（或任何相关原则）是在软件项目的实施和维护方面避免潜在陷阱/威胁的指南。仅仅盲目地遵循一个原则，而不知道它的反映是不会起作用的

作为你的例子，我将以OCP为例。OCP背后的关键概念是，如果您的项目100%符合OCP，那么任何其他人（可能是外人、新成员）都可以在不查看当前代码的情况下进行编码，而只是查看您的api文档（关于暴露的方法），这真的使该人的生活变得轻松。而且也不需要反复测试现有代码，因为不会对现有代码进行任何修改。但事实上，在某些情况下，我们必须打破OCP

例：

• 新需求（需要在现有类中实现）

• 错误修复

• 有限的框架支持（任何MVC框架）等

此外，在某些情况下，我们可能会违反OCP，因为我们知道这不会造成伤害

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

例：

• 走在左手边。（以便您可以看到入境车辆）

• 只能在人行横道上过街（这样车辆才能清楚地看到你，并停车）

尽可能地跟随他们肯定会让你安全。但想象一下，如果在几英里的道路上没有车辆，你还在寻找一个行人过路处来横穿马路吗？不是吗？即使不是人行横道，你也知道你是安全的。如果有一种情况，左手边的道路非常泥泞，无法行走，你还会继续在泥泞中行走，只是为了遵循这一原则吗？没有权利。你宁愿走在右手边了解情况

---

我想你对原则有了概念。：）

我想我发现了编写代码时必须考虑的第一件事。那就是单元测试。坚实的原则、设计模式等都是帮助进行单元测试的工具。据我所知，任何没有经验的程序员（像我一样）必须毫无例外地应用单元测试。测试结果已经引导程序员走向更好的设计。

谢谢你的回答。我怀疑我的设计。我想你的意思是使用更简单的模型，必须在第一阶段考虑SRP。我是对的吗？SRP是否有任何例外，或者我们应该双管齐下地应用SRP？每个规则都有例外，但我同意我们应该在任何地方都坚持SRP。但是我不会说我们应该盲目地应用它，因为它确实需要思考，因为“责任”这个词没有很好的定义。大师们知道什么时候该打破规则。我发现critisim关于SOLID。有人能同意他的观点吗？据我所知，SOLID不是OOP的主要法则。我认为主要法则是SOLID的原因，比如可维护性、可重用性、不重复自己等。当我们设计类时，我们应该首先考虑这些标准，如何管理数百个/数千个类？有什么要跟进的吗？关于这个问题，我有另一个问题，我没有得到任何答案。根据这个问题，我已经解释了什么时候使用哪个原则。我将很快回答她的问题。您必须使用工厂方法、抽象工厂、策略和门面模式。