简介
我处理有关继承问题的硕士论文，并提出一些建议。
指示存在继承问题的指示器。
类似于以下示例:
示例
public static String getAnimalNoise(Animal animal) {
if (animal instanceof Dog)
return "Woof";
if (animal instanceof Cat)
return "Miau";
return "";
}
如果给定的Animal实例是
"Woof"，则该方法返回String Dog；如果它是"Miau"，则返回Cat。空弦，因为有些动物根本不发出声音。因此，正确的解决方案应该是在Animal类中使用带有
getNoise方法的多态。我分析了继承问题的不同指标，并想说一下
其中一些违反了SOLID Principle。
我认为上述示例违反了:
但是我不太确定这是否对所有人都适用。
我想:
违反原则
违反SRP
因为条件语句完全违反了SRP，因为像开关一样
案例陈述或不止一个if-else陈述被视为不止一项责任。
它存在两种情况，因此有多种原因可以更改此方法。
违反OCP
因为如果添加了新动物，则必须将新案例添加到方法中
因此该方法尚无法修改。
违反LSP
每个分支根据动物子类型执行不同的 Action 。
我认为违反了LSP？
我知道矩形和正方形以及getArea的示例，但是这些
我认为也适合违规的例子。
违反规定
条件语句具有依赖性，这意味着语句取决于细节，而不取决于违反DIP的抽象。
问题:
因此，对于给定的示例，问题是，给定的原则是否确实受到违反，推理是否正确？
最佳答案
我非常不同意。 SRP是用少量盐来解释的。阅读Uncle Bob's article on it here-他创造了这个原理。
我将引用重要的内容:
正确的。该方法假定了一组特定的实现，并且如果不进行修改就无法处理新的实现。
它违反了LSP，但是出于不同的原因。如果我要传递长颈鹿，我会得到意想不到的结果，一个空字符串。这意味着该方法对于Animal的任何子类型都不正确。
从技术上讲是正确的，但这只是违反上述其他两个原理的副作用。这并不是问题的核心。
请记住，原则不是规则，因此在解释原则时，不要太严格/字面意义。实用主义和理解为什么需要原则是关键。
关于oop - 违反了哪些SOLID原则？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/30616660/