重写方法是违反 LSP 的唯一方法吗
Is overriding a method the only way to violate LSP
我一直在寻找代码中的迹象,这些迹象可以表明可能违反里氏代换原则。
首先我做了一个简单的 class 和另一个继承它的 class :
public class Adder
{
public virtual int Add(int operand1, int operand2)
{
return operand1 + operand2;
}
}
public class AdvancedAdder : Adder
{
}
然后我创建了一个检测 LSP 违规的单元测试:
public abstract class AdderUnitTestsBase
{
protected static Adder Adder;
[DataTestMethod]
[DataRow(2, 2, 4)]
[DataRow(-1, 2, 1)]
[DataRow(2, -3, -1)]
[DataRow(0, 0, 0)]
public void Add_ReturnsCorrectResult(
int operand1, int operand2, int result)
{
Assert.AreEqual(result, Adder.Add(operand1, operand2));
}
}
[TestClass]
public class AdderUnitTests : AdderUnitTestsBase
{
[ClassInitialize]
public static void ClassInit(TestContext context)
{
Adder = new Adder();
}
}
[TestClass]
public class AdvancedAdderUnitTests : AdderUnitTestsBase
{
[ClassInitialize]
public static void ClassInit(TestContext context)
{
Adder = new AdvancedAdder();
}
}
然后我尝试了不同的方法,例如更改参数类型或更改参数数量:
public class AdvancedAdder : Adder
{
public int Add(int operand1, int operand2, int operand3)
{
return operand1 + operand2 + operand3;
}
public uint Add(uint operand1, uint operand2)
{
return operand1 + operand2;
}
}
它没有违反LSP,因为方法有不同的签名。它只是扩展了功能。
唯一有效的方法是使用 "override" 关键字:
public class AdvancedAdder : Adder
{
public override int Add(int operand1, int operand2)
{
return operand1 - operand2;
}
}
看起来如果我在 C# 中避免 "override" 我就不需要担心可能违反 Liskov 的替换原则。 你认为它是正确的吗?
重写只是重新定义方法的一种技术方案。 LSP 更多的是关于语义而不是技术。
It looks like if I avoid "override" in C# I don't need to worry about possible Liskov's Substitution Principle violation.
也许你的意思是多态性,因为override
只是改变对象行为(动态绑定)的一种方式。您还可以将 new
用于非 virtual
方法(静态绑定)。您甚至可以使用检查(作为反射的特例)并基于此更改行为:
public void method()
{
switch (this.getType().Name)
{
case "Square":
// do the square thing
break;
case "Rectangle":
// do the rectangle thing
break;
}
}
像这样定义的方法可以很好地破坏 LSP 而无需继承或 override
/new
关键字。
它确实比普通的语法更复杂,而且更多关于语义(意思)。
即使是带有 squares/rectangles 的经典 LSP 示例也是关于意义的。如果您认为 square/rectangle 只是没有语义基础的单词,那么您对它们的行为没有任何期望。因此,你没有理由认为你可以用一个代替另一个并且不能破坏 LSP。
另一方面,继承是一种代码构造,告诉您:
PARENT
^
|
CHILD
The child can substitute the parent because it inherits all the behavior.
还值得一提的是,不应将 LSP 视为在任何情况下都必须执行的严格规则。
例如复合模式 (https://en.wikipedia.org/wiki/Composite_pattern) 可以为您提供一种以统一方式处理所有节点的机制(这很好)。但是,如果你以严格的方式解释 LSP,它就会违反 LSP。
与大多数面向对象的规则和设计模式一样,它只是一个指南,应该为您指明正确的方向,但可能会被其他要求否决。最后,架构的整体复杂性应该降低而不是增加。例如,这里的复合模式将允许您以更统一的方式处理对象并提供更简单的算法。
针对您的问题本身。如果您还考虑面向对象设计的消息传递,那么您还将拥有处理特定对象的类别 message/event 那么这也是打破 LSP 的一种方法(而不是仅使用虚拟和覆盖)。
最后你应该考虑到真相总是在中间的某个地方。
我一直在寻找代码中的迹象,这些迹象可以表明可能违反里氏代换原则。 首先我做了一个简单的 class 和另一个继承它的 class :
public class Adder
{
public virtual int Add(int operand1, int operand2)
{
return operand1 + operand2;
}
}
public class AdvancedAdder : Adder
{
}
然后我创建了一个检测 LSP 违规的单元测试:
public abstract class AdderUnitTestsBase
{
protected static Adder Adder;
[DataTestMethod]
[DataRow(2, 2, 4)]
[DataRow(-1, 2, 1)]
[DataRow(2, -3, -1)]
[DataRow(0, 0, 0)]
public void Add_ReturnsCorrectResult(
int operand1, int operand2, int result)
{
Assert.AreEqual(result, Adder.Add(operand1, operand2));
}
}
[TestClass]
public class AdderUnitTests : AdderUnitTestsBase
{
[ClassInitialize]
public static void ClassInit(TestContext context)
{
Adder = new Adder();
}
}
[TestClass]
public class AdvancedAdderUnitTests : AdderUnitTestsBase
{
[ClassInitialize]
public static void ClassInit(TestContext context)
{
Adder = new AdvancedAdder();
}
}
然后我尝试了不同的方法,例如更改参数类型或更改参数数量:
public class AdvancedAdder : Adder
{
public int Add(int operand1, int operand2, int operand3)
{
return operand1 + operand2 + operand3;
}
public uint Add(uint operand1, uint operand2)
{
return operand1 + operand2;
}
}
它没有违反LSP,因为方法有不同的签名。它只是扩展了功能。 唯一有效的方法是使用 "override" 关键字:
public class AdvancedAdder : Adder
{
public override int Add(int operand1, int operand2)
{
return operand1 - operand2;
}
}
看起来如果我在 C# 中避免 "override" 我就不需要担心可能违反 Liskov 的替换原则。 你认为它是正确的吗?
重写只是重新定义方法的一种技术方案。 LSP 更多的是关于语义而不是技术。
It looks like if I avoid "override" in C# I don't need to worry about possible Liskov's Substitution Principle violation.
也许你的意思是多态性,因为override
只是改变对象行为(动态绑定)的一种方式。您还可以将 new
用于非 virtual
方法(静态绑定)。您甚至可以使用检查(作为反射的特例)并基于此更改行为:
public void method()
{
switch (this.getType().Name)
{
case "Square":
// do the square thing
break;
case "Rectangle":
// do the rectangle thing
break;
}
}
像这样定义的方法可以很好地破坏 LSP 而无需继承或 override
/new
关键字。
它确实比普通的语法更复杂,而且更多关于语义(意思)。
即使是带有 squares/rectangles 的经典 LSP 示例也是关于意义的。如果您认为 square/rectangle 只是没有语义基础的单词,那么您对它们的行为没有任何期望。因此,你没有理由认为你可以用一个代替另一个并且不能破坏 LSP。
另一方面,继承是一种代码构造,告诉您:
PARENT
^
|
CHILD
The child can substitute the parent because it inherits all the behavior.
还值得一提的是,不应将 LSP 视为在任何情况下都必须执行的严格规则。
例如复合模式 (https://en.wikipedia.org/wiki/Composite_pattern) 可以为您提供一种以统一方式处理所有节点的机制(这很好)。但是,如果你以严格的方式解释 LSP,它就会违反 LSP。
与大多数面向对象的规则和设计模式一样,它只是一个指南,应该为您指明正确的方向,但可能会被其他要求否决。最后,架构的整体复杂性应该降低而不是增加。例如,这里的复合模式将允许您以更统一的方式处理对象并提供更简单的算法。
针对您的问题本身。如果您还考虑面向对象设计的消息传递,那么您还将拥有处理特定对象的类别 message/event 那么这也是打破 LSP 的一种方法(而不是仅使用虚拟和覆盖)。
最后你应该考虑到真相总是在中间的某个地方。