问题标签 [solid-principles]

我的项目中有类似的东西，该项目已经完成（它正在工作）我只是想知道它是否符合 SOLID 原则

用法是这样的

我知道这很明显它违反了 SRP，但是这个类是静态的，它包含彼此独立的静态方法，如果我为每个方法创建一个静态类，那是一样的

虽然不是纯粹的OOD原则——在考虑SOLID原则时是否也应该包括DRY？如果不是 - 为什么不呢？

我总是尝试应用SOLID原则，我真的很喜欢 Qt 工具包，但我发现自己一直在使用单一继承规则。

如果使用多重继承，moc 假定第一个继承的类是 QObject 的子类。 此外，请确保只有第一个继承的类是 QObject。

如何将 QObject 规则的单一继承与接口隔离原则结合起来。
我想用信号和槽定义接口，但我不允许这样做。

你如何克服这个缺点？

我读过来自 Matt Petters 的关于 DDD 的博客

并且据此据说我们为每个实体创建了一个存储库（接口），然后我们创建了一个 RepositoryFactory，它将提供存储库的实例（声明为接口）

这是使用 DDD 完成项目的方式吗？

我的意思是，我看到我认为他们使用 DDD 但他们直接调用每个存储库的项目，没有涉及工厂

并且

为什么我们需要创建这么多存储库类，为什么不使用类似的东西

我想这可能是违反 SOLID 原则的原因，还是其他原因？

如果我有类似的东西

这是否意味着我永远不应该使用 square 和 triangle 类而只参考图形？

就像从不这样做：

复合模式中的叶子实现了组件接口，包括Add叶子永远不会使用的方法Remove。GetChild这似乎违反了接口隔离原则。

那么 Composite Pattern SOLID的用法是什么？

复合模式链接：http: //www.dofactory.com/Patterns/PatternComposite.aspx

我已经向我的团队介绍了 SOLID 原则，他们理解并且对使用这些原则感到兴奋。

我给了他们几个已经被重构以使用这些原则的项目。我看到的最大问题是他们是否很难看到项目中非常松散耦合的类之间的联系。即使我创建了一个类图，它也不会显示任何连接。我所指的一个特定项目也使用依赖注入和 XML 配置来实现。虽然这样做的目的是让他们更难找出正在使用的类。

直观地显示类之间的关系以及它们在项目中的使用方式的最佳方式是什么？！

编辑：2008/10/24 8:40 PM

根据 UML 注释，我尝试使用内置的 Visual Studio 类图来构建应用程序模型。我可以给出每个接口的描述，但仍然不确定它们是否明确连接。

我知道盲目地遵循任何“最佳实践”仍然会导致一堆严格遵守最佳实践的臭屁。SOLID 原则就是这样，原则。它们并不适用于所有情况，但它们仍然是很好的启发式方法，可以在代码中找到可能的改进。

它们的缺点是它们有时需要对您的源代码进行深入分析才能应用它们。我和大多数程序员一样，一直在寻找更有效的做事方式。所以，我很好奇是否有人听说过一种分析工具，它试图测试 SOLID 原则的应用（或缺乏）。

SRP 单一职责原则

一个类应该只有一个改变的理由。

OCP 开闭原则

软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。

LSP 里氏替换原则

子类型必须可以替代它们的基本类型。

ISP 接口隔离原则

不应强迫客户依赖他们不使用的方法。接口属于客户端，而不属于层次结构。

DIP 依赖​​倒置原则

抽象不应依赖于细节。细节应该取决于抽象。

-来自 Robert C. Martin 的敏捷原则、模式和实践。

单一职责原则和关注点分离有什么区别？