信息专家、告诉而不是询问和单一职责原则经常被提及作为最佳实践方法。但我认为它们存在矛盾。这就是我的观点。 倾向于SRP的代码，但违反了Tell-Don't-Ask和Info-Expert原则： Customer bob = ...; // TransferObjectFactory has...

在SRP中，“责任”通常被描述为“修改原因”，这样每个类（或对象？）都应该只有一个人需要进去更改的原因。 但是，如果您将其细化到极致，您可以说将两个数字相加的对象是一种责任和可能的更改原因。因此，该对象不应包含任何其他逻辑，因为它会产生另一个更改原因。 我想知道是否有人有任何“作用域”策略...

每当我看到关于Demeter法则的文章时，作者似乎从未给出如何遵守该法则的实例。他们都解释了这是什么，并且展示了违反该法规的示例，但那太简单了。 可能有很多方式可以遵守这个法则（良好的设计和规划就是其中之一），但用非常简单的术语来说，这是否是遵守法则的一种方式？ 假设我有一个带有以下属性的...

介绍 大家好，我正在使用C#编写一个持久化库。在这个库里，我实现了仓储模式，但是我遇到了SOLID原则的问题。下面是一个简化版的当前实现，以便集中讨论关键问题： 在持久化库中包含的抽象仓储：public abstract class Repository<T> { pro...

根据SOLID原则，通过将switch条件转换为类和接口来消除它们通常更好。我想用以下代码实现此目标： 注意：这不是真正的代码，我只是把我的想法放进去了。 MessageModel message = getMessageFromAnAPI(); manageMessage(messa...

很抱歉这个问题有些主观，但我有点困惑，希望得到任何处理这个问题的人的指导和建议： 我编写了一个非常庞大的RESTful API项目，使用C# 2.0编写，我的一些类已经变得非常大。我的主API类就是其中一个例子 - 包含几十个成员和方法（可能接近数百个）。正如你所想象的那样，这已经成为一个小...

有没有一个特定的设计模式，描述了这样一种情况：提供非抽象默认实现，它使用空的NO-OP实现来实现接口上的所有或某些方法。这样做是为了减轻子类实现它们自己可能不需要/使用的方法的负担： public interface MyInterface { public void doThis(...

我对SOLID原则不太熟悉，但我了解它。我的主要问题是很难设计出符合SOLID原则的类，尤其是依赖倒置。有时将整个逻辑编写成过程模式比使用SOLID更容易。 例如: 假设我们正在创建一个考勤监控系统，并有一个逻辑（或过程）扫描员工指纹，获取其ID，确定它是否有效，确定他何时进入，写入登录信...

我的团队非常努力地坚持领域驱动设计作为一种架构策略。但是，大多数情况下，我们的领域实体相当无力。我们希望在我们的领域实体上放置更多的业务/领域行为。 例如，Active Record将数据访问放在实体上。我们不想这样做，因为我们很高兴使用仓储模式进行数据访问。 此外，我们设计软件时要遵循SOL...

高内聚性是否是单一责任原则的同义词？如果不是，它们有何不同之处？