问题标签 [open-closed-principle]

我正在尝试构建一个通用过滤器控件，它在数据网格中显示唯一值，并让用户过滤网格中特定列的唯一值。

我喜欢为这个问题提出的答案，但是所有这些都要求您事先了解该属性。我想让代码符合 OCP，并且只有一种方法可以获取属性名称字符串并在其上应用不同的函数（可能使用反射）。考虑到我的列（因此要过滤的列名，如名称、年龄等是动态的），这个问题的最佳解决方案是什么。

具体来说，我试图避免这种 switch case 语句：

并有一个像这样的通用方法：

仅供参考 - 我在 ViewModel 中的集合是 ICollectionView 类型（猜测在 CollectionView 中已经定义了类似的东西来执行我正在寻找的那种过滤）。

以下函数在 C 中实现：

每个分支都有不同的事情要做，不满足开闭原则（因为p指向的结构体不稳定，经常会添加新的字段，这意味着新的流程代码会经常添加到函数中） ; 如何修改它以满足OCP？

我被分配了一个家庭作业项目来弄清楚为什么代码片段不符合开闭原则，但我很难弄清楚。我在这里只是要求有人让我走上正确的道路，而不是为我完成作业。如果有人可以通过告诉我我在这段代码中寻找什么来帮助我，那将不胜感激。

想象一个应用程序，其中您有一个名为 Transaction 的类来表示金融交易。

这些事务可以根据事务类的属性值和一些业务规则进行分类。

一个名为 TransactionType 的枚举表示此类分类的可能值：Type1Transaction、Type2Transaction、NotRelevant。

Type1Transactions 和 Type2Transactions 会被报告，因为它们有些可疑，NotRelevant 交易不会被报告。

这种分类只是为了报告交易而有趣，并不代表 Transaction 类的内在属性（这就是为什么 Transaction 类没有代表这种分类的属性）。

好吧，此时我们要编写一个类，其职责是确定给定事务的分类，我们称之为 TransactionClassificator。

它的接口公开了一个方法GetTransactionType()，它的返回值为TransactionType。最明显的实现如下：

这种方法显然违反了 OCP 原则：它不接受修改，因为每次引入 enum TransactionType 的新值时都必须修改它。我不知道在这种特定情况下如何使用抽象来纠正违反 OCP 原则的问题。

感谢您的帮助。

恩里科

我想根据对象的类型对对象执行一些操作（数据库持久性、json 序列化等）。多态是执行此操作的常用方法，但我不想在我的模型中添加很多非业务逻辑。

这是一个简单的类型层次结构（这些不是我的原始类型，而是显示问题的简化）：

这些书在客户端作为 JS 对象创建，然后，它们以 JSON 的形式发送到服务器（我无法更改其结构），以解析为书籍列表：

然后，我想将此列表保存到数据库中：

我对 SaveBooksToDatabase 方法中的类型调度不满意：它违反了开闭原则，并且在我们添加新类型时不是很安全。

但是我不想在书籍层次结构中添加抽象的 Save() 方法，因为除了保存之外还有更多类型相关的操作（例如 json 序列化），这将违反单一责任原则。我知道访问者模式可能被认为是一种替代解决方案，但 IMO 它会引入更多混乱的样板代码。

处理此类案件的最佳和最优雅的方法是什么？

我正在尝试使用 android 中的 XML 保存一些数据以保存到设备内部存储中。

我想确保应用程序是由开放/封闭和单一责任原则编写的。（所以我可以轻松地在存储方法之间切换）

这是我目前的结构，...

我现在面临的问题是，在每个关于 android 和 xml 的教程中，他们使用的函数openFileOutput(filename,Context.Mode_Append)我猜这是来自 Activity 超类的函数？

我将如何初始化我的FileOutputStream并仍然保持我的开放/封闭和单一责任 原则完好无损？

我应该将 Activity 实例传递给我的 XMLAppWriter 构造函数吗？这不会破坏单一责任 原则吗？

我有一系列类型的集合，所有这些都派生自同一个基类，以及一组用于搜索每个类型的谓词，例如

有没有办法可以避免每种类型的重复？

我的下一步是采用 Dogs、Cats 并转换为常见的“结果”类型并返回这些相当简单的集合，但我觉得中间的重复应该被排除在外，以便我添加更多类型的动物未来它将干净地扩展。

在一个项目中，我有 3 个参与者（用户、专家、管理员）和 5 个主要用例（CRUD：创建、读取、更新、删除和同步）。但是用户对每个用例的访问权限与其他 Actors 不同。例如用户可以创建一个实体，但专家和管理员可以创建任意数量，等等其他用例：

此外，演员使用相同的用户界面。所以我必须在运行时决定启用或禁用当前演员的动作。这似乎很容易做到，但我喜欢有一个好的设计。特别是用例的数量，演员并且他们的访问权限级别可能会在以后更改。所以我必须尊重OCP原则。但是我如何才能有一个好的设计来管理用例和参与者的访问权限级别？

我下午的大部分时间都在阅读开放/封闭原则，但我似乎无法完全理解它。这是我已经阅读过的一些参考文章，似乎我错过了一些东西。

1. 了解开闭原则
2. 依赖注入的终结——谁创建了依赖？

假设我有一个基本的通用存储库，它公开了一些最通用的方法，可以满足存储库的任何需求。

存储库

然后，我希望专攻 ProductRepository。

产品资料库

让我们假设我从这里的基本存储库中获得了我需要的一切。如果是这样，那么我觉得我没有打破开放/封闭原则，因为我没有定义任何新成员或类似的东西。

但是，如果我需要一种特殊的存储库，比如说一个 AlertLevelConfigurationRepository，并且业务需求规定我一次只能拥有一个 AlertLevelConfiguration。因此，存储库需要始终获取当前配置。

警报级别配置存储库

现在，我觉得我打破了开放/封闭原则，因为这个新方法，因为这个类是从它的祖先修改后的派生类型。它被修改为存储库的基本定义不提供此GetCurrent方法。此外，我很确定我永远不会使用任何基本方法，除非该Save方法例外，因为更改级别配置可以是可配置的！

最后，我想知道我是否理解开放/封闭原则，不知何故我怀疑我理解。

我想知道这是否是一个违反原则的例子，如果不是，那么我想对原则本身进行一些解释。

我知道工厂方法相对于简单工厂的主要优势之一是它不违反开闭 SOLID 原则。也就是说，前者在添加新类型时不需要修改 switch 语句。

有一件我希望得到澄清。如果我要使用一个简单的工厂，我会有一个这样的工厂（简化）：

客户会这样称呼它：

文献中的缺点是添加新对象类型时需要修改 CreateObject。

但是使用工厂方法，我们不只是将这个修改从工厂移动到客户端，就像这样（客户端代码）：

在这种情况下，每次添加新类型时都需要修改客户端，而在前一种情况下，需要修改工厂。那么，一个比另一个有什么优势呢？请不要将此标记为重复，我查看了许多关于工厂的 SO 帖子，但没有一个解决这个特定的区别。

有没有更好的解决方案在客户端或工厂端都不会违反开放/封闭原则？