グローバルななにか
プログラム的な意味で言えば『あるアプリケーションあるいはシステムのライフサイクル中で常に参照可能な値』というところですか。
逆に言えば、常に変更される恐れがある信頼性の低い値とも言える。
なぜなら、いつ変更されるかわからないから。
昔ならいざ知らず、今のアプリケーションというものは基本的に複数のThreadで動作するのが当たり前です。
例えば操作の検知と描画の管理のために可能な限りmain threadでの動作を控えるだとか。
もっと言えばいつ終わるかわからない処理をmain threadで動作させてしまうとユーザの視点ではアプリがフリーズしてるように見えてしまったりする場合が多かったりするというアレですが。
まあ、だからこそグローバル変数というものが基本的に嫌われる傾向があったりする。
どこで何されるかわからない値だということですしね。
プログラム上信頼できる値というのは常に疎な状態です。
極論を言えば、メソッドスコープ内特有な値だけが信頼できるとも言える。
今の時代のコーディングって、一つのアプリに対してプログラマが数人から数十人アサインされたりするのもまあそこまで珍しいことじゃない分余計に、ですね。
私個人としては、別に処理中で使用する値が常に疎である必要があるとは感じてなかったりもしますが。
というか本当に完全な疎だけを使用すると引数のやりとりが異常なまでに増えすぎる場合がありますし。
というか突き詰めるとメンバー変数だとかああいうのもアウトになってきますし。（主に使ってる言語で言えばインスタンス変数とかそっちの方が正しいですが）
まあ、そこまでやってしまうと確かに想定外の値は入らないにしても生産性は酷く落ちることが多い。
それって≒で製造工程にかかる工数が肥大化するって意味ですよね、と。
プロジェクトによってはコストに糸目をつけない場合もなくはないんですけどね、それって酷く少数派。
基本的にプロジェクトというのは見積もり段階でコストの試算は終えてて、あとはどれだけその理想値に近づけていくかという作業でしかない部分もありますし。
そういう意味では、現実的に考えて完全に疎な値だけを使用したプロジェクトというのは難しい。
というか商品としてそこまでの価値がない場合が多い。
引数が増えるというのはその分、メソッドをコールする際のミス発生率が増えるというリスクがありますし。
特にデータ型が同じ引数が大量に並ぶ場合とか、間違ってても見かけ上普通に動いたりする場合もあるのが困りもの。
ある意味グローバル変数と同じくらい厄介な状態になる場合もなくはないですねというお話。
ついでにそういう潔癖な状態でアップデートを重ねていくとまず間違いなくパフォーマンスが下がる一方になる。
そういう意味でもそんな作り方は絶対しねぇだろうなぁ、とか、思わなくもないですね。
