Вопрос об объеме и инкапсуляции

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

Во втором подходе вы можете сделать _myFunction живым в отдельном модуле, не зависящем от глобального, - поэтому его проще тестировать, проще использовать повторно и помогает контролировать свой график зависимостей, который часто становится серьезная проблема в больших кодовых базах. Если вы вставляете зависимости, которых можно легко избежать, вы только усугубляете проблему с графом зависимостей, и очень немногие потенциальные выгоды могут когда-либо заплатить за ЭТО.

Действительно, чтобы получить такого рода преимущества, большой шаблон зависимостей заключается в явном INJECT-объекте, который в противном случае создал бы (как правило, нежелательные и нежелательные) зависимости между модулями - см. здесь для начала. Будучи фанатиком тестирования, слабой связи и повторного использования, я постепенно становлюсь фанатиком внедрения зависимостей, поэтому я не стану мечтать о доступе к глобальной константе, где передача ее в качестве аргумента является очевидной альтернативой ...; - ).

Answer 2

2 предпочтительнее, если вы хотите, чтобы один и тот же модуль компиляции был связан с обеими версиями (особенно как совместно используемая библиотека по глобально фиксированному пути), или если вы запускали несколько экземпляров в одном процессе. В противном случае, если вы находитесь в ситуации, когда перестройка всего из исходного кода не является препятствием, №1 лучше.

Некоторые вещи действительно глобальны. Глобальные константы вообще не опасны.