问题标签 [solid-principles]

我想避免 switch 语句。我有 30 多种文档类型。还有可能我需要添加更多的文档类型。我宁愿通过 IDocument 并在 IDocument 的实现中指定类型。我忘记提到的其他内容是 ProgressNoteViewModel、LabViewModel ...都从 WorkspaceViewModel 继承，并且所有具体的实现构造函数都将类型 IPatient 作为参数。我也使用 Castle 作为我的 IoC 容器

我想将代码重构为类似

我有以下代码：

出于我的目的，我需要在 xml 文件中搜索特定节点，如果找到，则将其删除。我应该将搜索功能提取到它自己的方法中并将功能删除到它自己的方法中吗？这样做似乎更昂贵，因为我将搜索 xml 文件一次以查看它是否存在并再次搜索以将其删除。如果我将这两个功能组合成一个方法，我可以在找到它时立即删除它。我在这里正确理解 SRP 吗？

在 SRP 中，“责任”通常被描述为“改变的理由”，因此每个类（或对象？）应该只有一个理由，有人应该去那里改变它。

但是如果你把它带到极端的细粒度上，你可以说一个对象将两个数字加在一起是一种责任，也是改变的可能原因。因此对象不应该包含其他逻辑，因为它会产生另一个变化的原因。

我很好奇是否有人有任何“范围界定”策略，单一责任原则稍微不那么客观？

假设我们正在设计一个执行 CRUD（创建、读取、更新和删除）操作的 UserServiceImpl 类。在我看来，创建、读取、更新和删除是更改类的四个原因。这个类是否违反了单一职责原则？如果它违反了，那么我们应该有四个类，如CreateUserServiceImpl、ReadUserServiceImpl、 UpdateUserServiceImpl和DeleteUserServiceImpl。有很多课程不是矫枉过正吗？

假设我为创建、读取、更新和删除操作分别定义了 4 个接口，并且我的服务类实现了所有四个接口。现在我只能有一个实现类，但通过分离它们的接口，就应用程序的其余部分而言，我已经解耦了这些概念。这是正确的方法还是您发现其中存在一些问题？

维基百科这样描述单一职责原则：

单一职责原则指出每个对象都应该有单一职责，并且该职责应该完全由类封装。它的所有服务都应与该责任密切相关。

MVC 中对控制器的传统使用似乎导致程序员违反了这一原则。拿一个简单的留言簿控制器并查看。控制器可能有两种方法/动作：1) Index() 和 2) Submit()。Index() 显示表单。Submit() 处理它。这两种方法是否代表两种不同的职责？如果是这样，单一职责如何发挥作用？

这个首字母缩写词中的第一个字母代表的设计模式是单一责任原则。这是一个报价：

单一职责原则指出每个对象都应该有单一职责，并且该职责应该完全由类封装。

在我们开始编码之前，这很简单明了。假设我们有一个定义明确的单一职责的类。要序列化类实例，我们需要向该类添加特殊属性。所以现在这个班级有另一个责任。这不违反 SRP 吗？

让我们看另一个例子——一个接口实现。当我们实现一个接口时，我们只需添加其他职责，比如处理它的资源或比较它的实例等等。

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

使用虚拟方法是否违反LSP （ SOLID原则的 L 部分）或有一些例外？

在此先感谢，萨格哈·阿亚兹

我的团队正在使用自制的 DI 容器在 PHP 项目中实现依赖注入。我们对 DI 的第一次迭代可能被带到了极端，甚至将异常注入到依赖它们的类中。

这是一个好习惯还是矫枉过正？

我第一次尝试坚持 Robert Martin 的 SOLID 设计原则，但我并不擅长。

本质上，我需要一个“节点”对象的层次结构。有些节点是 NodeHost，有些是 NodeChildren，有些是 Both。每个人以前都做过这个，但我不知道如何在不使设计过于复杂或在节点子类型中做类似事情的情况下做到这一点：

这违反了里氏替换原则对吧？有什么更好的方法？这就是我现在所拥有的。

我们正在对我们的系统进行一些重大更改，我想知道实施这些新业务逻辑规则的最佳方法，同时尊重 SOLID 原则：

开放/封闭原则说“开放以进行扩展，但关闭以进行修改”好的，但我该如何进行修改？我的意思是，我不想保留旧的业务逻辑，而在我看来“扩展”主要是指“添加代码”而不是“更改代码”，那么我理解错了什么？