開発者が作成するほとんどのアプリケーションは、起動時に外部でパラメーター化する必要があります。ファイルパス、パイプ名、TCP/IPアドレスなどを渡します。これまでのところ、コマンドラインを使用して、起動中のアプリケーションにこれらを渡しています。私はmain
のコマンドラインを解析して、引数を必要な場所に向ける必要がありました。もちろん、これは良いデザインですが、多数の引数に対して維持が難しい。最近、環境変数メカニズムを使用することにしました。それらはグローバルであり、どこからでもアクセスできます。つまり、アーキテクチャの観点からはあまりエレガントではありませんが、はコードの量を制限します。
これらは両方の戦略に対する私の最初の(そしておそらくかなり浅い)印象ですが、より経験豊富な開発者の意見を聞きたいと思います-環境変数とコマンドラインを使用することの利点と欠点は何ですか引数をプロセスに渡すには?次の点を考慮したいのですが。
備考:
広告。 1.これは私が興味を持っている主要な側面です。
広告。 2.これは少し実用的です。現在 huge であるWindowsのいくつかの制限を知っています(コマンドラインと環境ブロックの両方で32kB以上)。必要であれば、ファイルを使用して大量の引数を渡す必要があるため、これは問題ではないと思います。
広告。 3. Unixについてはほとんど何も知らないので、両方の戦略がWindowsと同じように使用できるかどうかはわかりません。よろしければ、これについて詳しく説明してください。
1)できるだけ環境変数を回避することをお勧めします。
環境変数の長所
環境変数の短所
私の意見
They are global and accessible from anywhere, which is less elegant from architectural point of view, but limits the amount of code
グローバル変数の使用の正当化を思い出させます;)環境変数の酷使の恐怖を直接体験したことによる私の傷跡
2)制限
コマンドラインが保持できるもの、または環境が処理できるもののいずれかの制限を押し進めていた場合、すぐにリファクタリングします。
過去には、多くのパラメーターを必要とするコマンドラインアプリケーションにJSONを使用しました。文字列や数値とともに、辞書やリストを使用できるのは非常に便利でした。アプリケーションはコマンドライン引数を2、3だけ取り、そのうちの1つはJSONファイルの場所でした。
このアプローチの利点
What won't fit into command line parameters?
)リストなど注:これを.config-fileアプローチと区別したい-これはユーザー設定を保存するためのものではありません。コマンドラインに適合しない多くの値を必要とするプログラムに使用するため、これを「コマンドラインパラメータファイル」アプローチと呼ぶ必要があるかもしれません。
3)ソリューションの移植性:Mac、PC、Linuxの環境変数とコマンドライン引数の違いについてはよくわかりませんが、次のように説明できます。
はい、わかりました。あまり役に立ちませんでした。申し訳ありません。しかし、重要な点は、あなたがcanは、移植可能であることが合理的な解決策であると期待していることです。プラットフォーム?わからない)。
最後のポイント:
Tomaszが述べたように、パラメーターが由来するほとんどのアプリケーションでは問題になりません。
Strategy パターンを使用して、読み取りパラメータを抽象化する必要があります。次の実装を使用して、readConfig(key) -> value
メソッドを持つ(またはConfigurationSource
オブジェクト/構造を返す)Configuration
という名前の抽象化を作成します。
CommandLineConfigurationSource
EnvironmentVariableConfigurationSource
WindowsFileConfigurationSource
-C:/Document and settings...
の構成ファイルからロードWindowsRegistryConfigurationSource
NetworkConfigrationSource
UnixFileConfigurationSource
--/home/user/...
から構成ファイルからロードDefaultConfigurationSource
-デフォルトチェーンの責任 パターンを使用して、次のようなさまざまな構成でソースをチェーンすることもできます。コマンドライン引数が指定されていない場合は環境変数を試し、それ以外がすべて失敗した場合はデフォルトを返します。
広告1.このアプローチでは、読み取り設定を抽象化できるだけでなく、クライアントコードに影響を与えることなく、基になるメカニズムを簡単に変更できます。また、一度に複数のソースを使用して、異なるソースから構成をフォールバックまたは収集することもできます。
広告2.適切な実装を選択するだけです。もちろん、一部の構成エントリは、たとえばコマンドライン引数に適合しません。
Ad 3.一部の実装が移植可能でない場合は、2つ用意してください。1つは、特定のシステムに適さない場合、黙って無視/スキップされます。
この質問にはすでにかなりの回答が出ていると思いますが、2018年の更新に値するものだと思います。環境変数の言及されていない利点は、一般に、作業に必要なボイラープレートコードが少なくて済むことです。これにより、コードがより読みやすくなります。ただし、大きな欠点は、同じマシンで実行されているさまざまなアプリケーションから分離のレイヤーが削除されることです。 Dockerが本当に素晴らしいのはこれだと思います。私のお気に入りの設計パターンは、環境変数のみを使用し、Dockerコンテナー内でアプリケーションを実行することです。これにより、分離の問題が解消されます。