违反了哪些SOLID原则？

Question

介绍

---

我研究了关于继承问题的硕士论文,并找出了一些表明存在遗传问题的指标.

如下例所示:

例

---

public static String getAnimalNoise(Animal animal) {
  if (animal instanceof Dog)
    return "Woof";
  if (animal instanceof Cat)
    return "Miau";
  return "";
}

"Woof"如果给定的Animal实例是a Dog并且"Miau"它是a ,则该方法返回String Cat.空绳子,因为有些动物根本没有噪音.

因此,正确的解决方案应该是使用多态与getNoiseAnimal类中的Method.

我已经分析了继承问题的不同指标,并想说一些是否违反了SOLID原则.

我认为上面的例子违反了:

1. 单一责任原则(SRP)
2. 开放/封闭原则(OCP)
3. Liskov替换原理(LSP)
4. 依赖倒置原则(DIP)

但我不确定这是否适用于所有人.

我想:

原则上的违规行为

---

SRP违规

因为条件语句完全违反了SRP,因为像switch语句或多个if-else语句一样会考虑多个责任.

它存在两种情况,因此改变方法的原因不止一个.

OCP违规

因为如果添加新动物,必须在方法中添加新案例,因此方法不会接近修改.

LSP违规

每个分支执行依赖于动物子类型的不同动作.我认为这违反了LSP？!我知道矩形和正方形以及getArea的例子,但我认为这些例子也适用于违规.

DIP VIOLATION

条件语句具有依赖性,这意味着语句依赖于细节,而不依赖于违反DIP的抽象.

题:

---

因此,对于给定的例子,问题是真正违反的给定原则并且推理是否正确？

Answer 1

SRP因为条件语句完全违反了SRP,因为像switch语句或多个if-else语句一样会考虑多个责任.它存在两种情况,因此改变方法的原因不止一个.

我非常不同意.SRP旨在用少量的盐来解释.在这里阅读鲍勃叔叔的文章 - 他创造了这个原则.

我会引用一些重要的内容:

什么定义了改变的理由？

这个原则是关于人的.

当您编写软件模块时,您希望确保在请求更改时,这些更改只能来自一个人,或者更确切地说,来自一个紧密耦合的人群,代表一个狭义的业务功能.您希望将模块与整个组织的复杂性隔离开来,并设计您的系统,使每个模块负责(响应)仅一个业务功能的需求.

[...]当你想到这个原则时,请记住改变的原因是人.是要求变更的人.并且您不希望通过将许多不同人关心的代码混合在一起来混淆那些人或者您自己.

OCP因为如果添加了新动物,则必须在方法中添加新案例,以便方法不会因修改而关闭.

正确.该方法假设一组特定的实现,并且无法在不进行修改的情况下处理新的实现.

LSP每个分支执行依赖于动物子类型的不同动作.我认为违反了LSP？!

它违反了LSP,但原因不同.如果我要传入长颈鹿,我会得到一个意想不到的结果,一个空字符串.这意味着该方法对于任何子类型都不正确Animal.

DIP条件语句具有依赖性,这意味着语句依赖于细节,而不依赖于违反DIP的抽象.

技术上是正确的,但这只是违反上述其他两个原则的副作用.这不是问题的核心.

请记住,原则不是规则,因此在解释原则时不要太严格/字面意思.实用主义和理解为什么需要原则是关键.