欢迎！请参阅 关于 页面获取有关该功能的一些更多信息。
fn 特殊形式和 defn 宏允许前条件和后条件。如果能在大纲说明表中使用这些条件，那就更好了。
目前我使用 extend 函数作为替代方案，可以指定使用关键字名称列表和 fn 特殊形式的方法。
评论由：michael-drogalis 发表
在我看来，使用 {{:pre}} 和 {{:post}} 并不是一个好主意。断言处理是一个两部分的游戏。该机制需要考虑到检测和反应，而后一部分是缺失的。
这不是一个完美的替代方案，因为它的语句有点冗长，但使用（链接： https://github.com/MichaelDrogalis/dire 文本：Dire）可能比使用 extend 更好。此外，您还将获得 {{:pre}} 和 {{:post}} 中缺少的“反应”功能。
协议前条件的示例： https://gist.github.com/4471276
评论由： akiel 发表
@Michael 我读了你（链接： https://gist.github.com/4471276 文本：gist）和（链接： https://github.com/MichaelDrogalis/dire 文本：Dire）的 README。我认为 Erlang 的监督概念有其位置，但我不喜欢它在前条件和后条件中。对我来说，这样的条件有两个目的
为了支持我的第一个观点，您的预条件和后条件与实际函数定义在词汇层面上过于遥远。对于第二个观点：我认为在违规的情况下，程序应该直接崩溃。可能有人会使用您的异常管理器来处理AssertionError。但是，我不认为处理单个函数的预条件和后条件违规是一件好事。
@Alexander 当然，你的观点是正确的。Dire正打算如你所描述的那样。从应用逻辑中分离出来，并有机会从崩溃中恢复。无论如何，这都是我尽快帮助你的最好办法。:)
我想这不是因为相关的接口可以实现在Java中而不可行的。任何这样的实现都不会包含预条件和后条件，这可能会破坏假设。
