design-patterns - 具有粒度方法和属性访问的编程语言

Question

想象一下这样的事情:

import class B.*;


interface A supports A.testSum
{
   int sum( int a , int b ) access from B.calculator;

   testSum() { Assert(sum(1,1)==2); }

........


class B ...
{
  void calculator() {  A.sum(3,5); //ok }
  void someOtherMethod() { A.sum(0,3); //compile error }

“支持”的想法是次要的，但相关，因为在这种情况下测试适用于接口(interface)(因此语言将区分所有实现都必须通过的接口(interface)测试和特定于该接口(interface)的实现测试)实现私有(private)

但我想在这里传达的重要思想是访问控制语义；请注意，带有“access from”关键字的 A.sum 只能从方法 B.calculator 中调用。其他任何内容都会被检测为编译时错误。这里的想法是以更细粒度的方式强制实现架构约束。如果您没有添加“访问自”或仅添加“访问自*”，则意味着允许从任何地方调用该方法的默认行为。什么样的架构限制？嗯，在进行分层设计时手动强制执行的那种:从层B(中级)开始使用层A(最低层)，然后从层C(高层)开始使用层A(最低层)。但是 B 层无法从 A 层访问，C 层也无法从 A 或 B 访问，但否则它是公共(public)的(可能是最终用户可以直接访问的)

问题:你知道有什么语言(包括源到源的中间语言)支持上述语义吗？讨论这种语义是否会适得其反、危险或只是鼓励糟糕的设计的额外要点

更新:这种限制还有另一个非常重要的用例:

事件驱动编程:事件的问题通常是事件往往会做太多事情，并且理解事件的依赖链可能会变得棘手

例如，可以定义事件处理程序仅具有可以与之交互的某些可见类(或者相反，它无法触及的某些对象集)

Answer 1

这听起来有点像 object-capability model 的一个特例。 。也许有一些语言以某种方式实现了这一点。

同样，快速谷歌搜索“方法级安全性”让我发现了企业 Java 社区似乎已经炮制的一些东西。我认为将这种方法专门用于方法调用是毫无意义的。除非你有充分的理由这样做，否则我认为这可能是一个坏主意。如果出于某种原因您确实有兴趣这样做，那么实际上模型应该是让接收者检查调用源是否在某个允许的集合中。

无论如何，这基本上严重破坏了大多数编程模型。您最好强制执行前提条件和类不变量，以确保任何方法调用(从任何地方!)都是有意义的或行为良好的。如果您使用它来强制方法排序，则可以使用不变检查(静态或运行时)或理论模型(例如Interface Automata)来实现。 .