静的グローバル変数はグローバル変数と同じくらい悪いですか？それらの使用を避ける方法は？
一般的に、グローバル変数は良くないので避けるべきです。静的グローバル変数も同様に悪いですか？
私のすべてのプロジェクトでは、静的グローバル変数に大きく依存しています。デザインの観点から、それらを使用しないようにする方法を教えてください。
元の使用例：
キーが変更されると（他のスレッドによって）、コールバック通知が実行され、静的グローバル変数が新しいキーで更新されます。このキーは、プログラムのあらゆる場所で一部のデータを復号化するために使用されます。
この場合、静的グローバルをどのように回避できますか？
キーが変更されると（他のスレッドによって）、コールバック通知機能が実行され、静的グローバル変数が新しいキーで更新されます。このキーは、プログラムのどこでも使用され、一部のデータを復号化します。
このような考え方にとらわれているのが「鍵」の概念です。それは「鍵」であるべきです。
キーはグローバルであると考えるので、それを保持するものはすべてグローバルでなければなりません。要件の変更を想像してみてください。突然、5つのキーが動き回っています。
想像できませんか？ほぼ同じことをする5つのシステムを想像してみてください。それらは異なるキーを持ち、すべてがアプリケーションの一部である必要があります。どのくらいのコードを再利用できますか？
キーはコンテキストに属しています。そのコンテキスト内では、キーは1つだけです。ただし、これはコンテキストが1つしかないという意味ではありません。
「1つの真のキー」を知ってすべてのユーザーにこのキーを見つけるように強制するのではなく、関心のあるキーを見つけるための何らかの方法を渡すことで、どのコンテキストにいるかを伝えます。
つまり、キーは1つの場所にのみ保存されます。しかし、今はその場所がどこかを決める場所は1つだけです。あなたがそれをグローバルにした場合、すべてはそれがどこにあるかを知り、それがどこにあるかについて同意しなければなりません。いや。
静的グローバル変数は同じグローバル変数ですが、@ 5gon12ederが上記に気づくように、コンパイル時の可視性が制限されています。
グローバルな静的状態は競合状態になりがちです。この状態にアクセスする複数のスレッドがある場合は、ロックが必要になることがあります。値を変更できるスレッドが1つしかない場合でも、他のスレッドが値のコピーを一度作成し、同じ値を返すグローバル変数の繰り返し読み取りに依存しない限り、競合状態が発生する可能性があります。
あなたがロック処理コードを書くことに熟練しているなら、あなたはそれで大丈夫かもしれません。しかし、おそらくあなたはこの質問をしないでしょう。
シングルスレッドプログラムを使用している場合、これらの問題はほとんどなくなります。残りの問題は、グローバルな値を介した機能間の説明されていない相互作用にある可能性があります。
これはすべてよく知られているので、まとめて説明します。
グローバル変数の最大の問題は、それがグローバルであるため、だれでもいつでもアクセスして変更できることです。静的変数を使用すると、この問題は大幅に軽減されます。これは、変数にアクセスして変更するすべてのコードがその1つのファイルにあり、うまくいけばユーザーの制御下にあるためです。 （「静的グローバル」変数などはありません。それは自己矛盾です。アプリケーションと同じ存続期間を持つ静的変数を意味します）。
グローバル変数の2番目の大きな問題は、1つではなく2つ以上必要な場合があることです。はい、その問題は同じままです。 oneグローバル変数しかないという事実によってコードが制限されている場合は、機能が失われるか、コードがスレッドセーフにならない可能性があります。これは問題であり、静的変数でもグローバル変数と同様に処理する必要があります。
言語によっては、問題を引き起こすのは明白な変数である場合があります。プレーン変数は通常、事前の予防策なしにアクセスできます。それが問題である場合、おそらくいくつかのアクセサ関数が必要です。アクセサーのみがアクセスできる静的変数があるでしょう。これは、問題が単にグローバルな状態にある場合には役立ちませんが、問題がそのグローバルな状態への制御されていないアクセスである場合には役立ちます。
あなたは正しい質問をしています。設計の観点から、グローバル変数の使用を避けるために何ができるでしょうか。
ここでの大きな手がかりは、グローバル変数に大きく依存しているということです。これは、設計が十分にモジュール化されていないことを示しています。これは、小さくてわかりやすいループから醜い獣に成長した厄介な古い組み込みプロジェクトでこれまでに見たことがあります。
優れたモジュール設計には、これらのグローバルの使用を排除し、TDDをはるかに簡単にするなど、多くの利点があります。単体テストがはるかに簡単です。モジュールには、モジュールに対して「グローバル」な独自の内部静的データがある可能性がありますが、モジュールの外部にはアクセスできません。プログラムの他の部分が作業を行えるように、必要に応じてアクセス関数を作成します。このアプローチでは、自分が何をしているのかを注意深く考え、特定の作業を行うモジュールを試して構築する必要があります。
このアプローチの副次的な利点は、これらのモジュールの機能がより一般的なものになったため、他のプロジェクトでこれらのモジュールを再利用できるようになることです。