实现具有较弱后置条件的接口的接口具有更强的后置条件 - 如何实现？ [英] Stronger postconditions for interfaces that implement interfaces with weaker postconditions - how?
问题描述
假设我们正在编写一些库，例如为了在屏幕上绘图，并允许我们的客户与我们的库进行通信，我们还编写了一个API，其中包含一些接口，用于描述客户端应该将哪些数据传递给我们的
库方法，回调API等似乎不仅代码契约完全适合那里，而且它可能是代码契约设计的主要原因。
Let's say we're writing some library e.g. for drawing on the screen, and to allow our clients to communicate with our library, we're also writing an API, which contains, among other things, some interfaces describing what data should clients pass to our library methods, callback API etc. It seems that not only Code Contracts perfectly fit there, but that it might be the primary reason Code Contracts were designed at all.
接口当然不包含任何数据，所以没有必要把它们变成抽象类。另外，客户端可能希望从其他类（例如来自他们的SuperDataEntity）派生他们的类，所以我们甚至应该
避免将接口转换为抽象类。
The interfaces, of course, do not contain any data, so there is no need to turn these into abstract classes. Additionally, the client will possibly want to derive their classes from some another classes (e.g. from their SuperDataEntity), so we even should avoid turning the interfaces into abstract classes.
但是，我们的数据模型是 enterprisey ，我们不能没有继承接口。所以，最后，我们在基础库中得到类似的东西：
However, our data model is so enterprisey, that we cannot live without inheritance in interfaces. So, in the end, we get something like that in our base library:
[ContractClass(typeof(ContractShape))]
interface IShape
{
int numberOfVertices
{
get;
}
}
[ContractClassFor(typeof(IShape))]
abstract class ContractShape : IShape
{
#region IShape Members
public int numberOfVertices
{
get {
Contract.Ensures(Contract.Result<int>() > 0);
throw new NotImplementedException();
}
}
#endregion
}
[ContractClass(typeof(ContractTriangle))]
interface ITriangle : IShape {
bool amIRight {
get;
}
}
[ContractClassFor(typeof(ITriangle))]
abstract class ContractTriangle : ITriangle {
#region ITriangle Members
public bool amIRight
{
get { throw new NotImplementedException(); }
}
#endregion
#region IShape Members
public int numberOfVertices
{
get {
Contract.Ensures(Contract.Result<int>() == 3);
throw new NotImplementedException();
}
}
#endregion
}
推荐答案
它似乎应该得到支持，但也许有阻止它的一些技术限制。
It does seem like it should be supported, but perhaps there's some technical limitation preventing it.
无论如何，我没有看到在这里使用抽象类的问题，因为你的界面实际上包含数据，即使你巧妙地编码了它以后置条件的形式。 ：）&NBSP;如果你想确保一个
属性的值总是与它的接口类型一致，那就是数据。
Regardless, I don't see the problem with using an abstract class here since your interface does actually contain data, even though you've cleverly encoded it in the form of a post-condition. :) If you want to ensure that the value of a property is always consistent with the type of its interface, that's data.
但也许这只是一个临时的例子？ ;如果你必须坚持使用接口，那么你至少可以尝试在具体的实现中加强后置条件。 我相信静态检查器会尊重它。 无论你将后置条件放在界面还是你自己的具体类型，都有
真的没什么区别;但是，如果您的消费者负责提供实施，那么我想使用抽象类是您唯一的选择。
But perhaps this is just a makeshift example? If you must stick with interfaces, then you can at least try strengthening the post-condition in a concrete implementation instead. I believe the static checker will honor it. There's really no difference whether you put the post-condition in the interface or your own concrete type; however, if your consumers are responsible for providing implementations, then I guess using an abstract class is your only choice.
- Dave
这篇关于实现具有较弱后置条件的接口的接口具有更强的后置条件 - 如何实现？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
