Question

我有关于范围和封装的一般性问题。采取两种方案：

情景1：

// a global application level constant
public static const IS_DEMO_MODE:Boolean = false;   

... // somewhere deep in the codebase

private function _myFunction():void
{
    if (IS_DEMO_MODE == true) {
      // If Demo Mode do not allow this function to complete
      return;       
    }
    else {
       // Function behaves normally
       // Code ...
    }

}

情景2：

// a global application level constant
public static const IS_DEMO_MODE:Boolean = false;   

... // somewhere deep in the codebase

 // call the function and pass in the constant
_myFunction(IS_DEMO_MODE);


private function _myFunction(isDemoMode:Boolean):void
{
    if (isDemoMode == true) {
      // If Demo Mode do not allow this function to complete
      return;       
    }
    else {
       // Function behaves normally
       // Code ...
    }

}

从功能上讲，这两个代码片段完全相同。我试图理解编码风格的细节以及为什么一种方式可能比另一种方式更受欢迎？从封装的角度来看，情景2似乎更好。但是场景1更加简单，因为条件中的布尔值仅来自一个地方，即全局常量。您不必担心函数调用，而正确接收参数可能会传入错误的值。但是场景2看起来是值得的，因为你删除了常量的依赖性，并且可以让函数表现得更动态。有什么想法吗？我还在寻找其他权衡吗？

同样的概念和问题也适用于对象和类。但我只是为了简化代码示例而在函数方面提供了示例。

Answer 1

如果您希望将相同的编译单元链接到两个版本（特别是作为全局固定路径中的共享库），或者如果您在同一进程中运行多个实例，则首选

2。否则，如果您处于从源头重建所有内容不是障碍的情况，那么＃1会更好。

有些事情确实是全球性的。全局常数根本不危险。

Answer 2

在第二种方法中，您可以将_myFunction置于一个单独的模块中，不受全局模块的依赖 - 因此它更容易测试，更容易重用，并帮助您控制依赖图，这通常是在大型代码库中成为一个严重的问题。如果您插入可以轻松避免的依赖关系，那么您只会使依赖关系图问题变得更糟，并且很少有潜在的好处可能会为此付出代价。

实际上，为了获得这种优势，一个很好的依赖模式是显式INJECT对象，否则会在模块之间创建（通常是不期望的和不期望的）依赖关系 - 请参阅here作为开始。作为测试，松散耦合和重用的狂热分子，我逐渐成为依赖注入的狂热者，所以我不会梦想访问一个全局常量，将其作为参数传递是一个明显的选择......; - ）。

关于范围和封装的问题

2 个答案: