Une question sur la portée et l'encapsulation

Question

J'ai une question générique sur la portée et l'encapsulation. Prenez deux scénarios:

Scénario 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 ...
    }

}

Scénario 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 ...
    }

}

Sur le plan fonctionnel, ces deux extraits de code font exactement la même chose. J'essaie de comprendre les subtilités du style de codage et pourquoi une méthode pourrait être préférée à une autre? Il semble que le scénario 2 soit meilleur du point de vue de l’encapsulation. Mais le scénario 1 est plus infaillible en ce que le booléen au conditionnel provient d’un seul endroit, la constante globale. Vous n'avez pas à vous soucier d'un appel de fonction qui, tout en recevant correctement un paramètre, pourrait transmettre une valeur incorrecte. Mais le scénario 2 semble intéressant car vous supprimez la dépendance de la constante et pouvez faire en sorte que la fonction se comporte de manière plus dynamique. Des idées à ce sujet? Y a-t-il d'autres compromis que je cherche à résoudre?

Même concept et même question appliqués aux objets et aux classes. Mais je viens de présenter l’exemple en termes de fonction pour simplifier l’exemple de code.

Answer 1

Dans la deuxième approche, vous pouvez placer _myFunction dans un module séparé, sans dépendance du module global. Il est donc plus facile de tester, de réutiliser et de contrôler le graphique de dépendance. , ce qui devient souvent un problème sérieux dans les grandes bases de code. Si vous insérez des dépendances que vous pouvez facilement éviter, vous ne faites qu'aggraver le problème du graphe de dépendance et très peu d'avantages potentiels pourraient éventuellement payer pour CELA.

En effet, pour obtenir ce type d’avantages, un modèle de dépendance important consiste à INJECTER explicitement un objet qui, autrement, créerait des dépendances (généralement indésirables et non désirées) entre les modules - voir ici pour commencer. Fanatique d'essais, de couplages lâches et de réutilisation, je deviens aussi un fanatique d'injection de dépendances aussi, alors je ne voudrais pas accéder à une constante globale où le passer comme argument est une alternative évidente ...; - ).

Answer 2

2 serait préférable si vous souhaitez que la même unité de compilation soit liée aux deux versions (en particulier en tant que bibliothèque partagée dans un chemin globalement fixé), ou si vous avez exécuté plusieurs instances dans le même processus. Sinon, si vous êtes dans une situation où tout reconstruire à partir de la source n’est pas un obstacle, le n ° 1 est préférable.

Certaines choses sont vraiment mondiales. Les constantes globales ne sont pas du tout dangereuses.