設定ファイルを読み書きする時は専用のクラスを作れ [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/08/20(日) 23:54:22.47

よっぽど小さいプログラムでない限り
YAMLやJSONなどを読み込んでハッシュにしたものを参照するのではなく
設定ファイルクラスを作ってアクセスするべきである
理由は拡張性や互換性を保ってシンプルに使えるようにするため

**デフォルトの名無しさん** · 2017/08/21(月) 00:15:34.85

-完

**デフォルトの名無しさん** · 2017/08/21(月) 00:16:19.90

再開

**デフォルトの名無しさん** · 2017/08/21(月) 01:01:36.37

これは誰も反対するやついないわ
つかわざわざ自作しなくても標準でそういう機能が用意されてるか
一般的によく使われてるライブラリがあると思うぞ

**デフォルトの名無しさん** · 2017/08/21(月) 01:36:10.97

xmlを使ってたけど
でかくなると文字列処理だから
超おっそいぜ

**デフォルトの名無しさん** · 2017/08/21(月) 01:47:39.56

>>1
この程度の処理大事にするほどのもんかなぁ?
dobon貼れば終わるんだろ?

**デフォルトの名無しさん** · 2017/08/21(月) 01:49:20.42

読み込みクソ重いのに
20msに一回とか言われっと
速度ベースで考えないと駄目なときも

**デフォルトの名無しさん** · 2017/08/21(月) 09:34:07.48

>>4
> つかわざわざ自作しなくても標準でそういう機能が用意されてるか
> 一般的によく使われてるライブラリがあると思うぞ

いや違う。そういう話じゃない。
例えばApacheであればApache専用の設定クラスを作るということ
そして自作のMyAppであればMyAppConfigという専用のクラスを作るということ

**デフォルトの名無しさん** · 2017/08/21(月) 10:52:50.57

まんこはマジ臭い
ちんこの比じゃない

**デフォルトの名無しさん** · 2017/08/21(月) 11:09:33.97

ケースバイケースじゃん
そもそもどこに持つんだよ?
ってのと
通信設定なのかログ設定なのか
製品設定なのか表示設定なのか
ユーザ毎の設定なんてデータベースだし
あの場合はこの場合は?
ってすべてを包括できるもんはできんと思うがどうか?

**デフォルトの名無しさん** · 2017/08/21(月) 12:41:30.44

>>10
だからこそ、その違いをクラスで吸収するんだよ

もし専用のクラスがなかったら、その設定項目を利用するたびに
ファイルから取得しようかデータベースから取得しようか
考えないといけなくなるだろ

**デフォルトの名無しさん** · 2017/08/21(月) 12:48:33.17

例えば、ある設定値を取得する場合を考える。

具体的にログのファイル名とするか？
設定ファイルで設定している場合は、そのファイル名
そうでなければ /tmp/myapp.log に出力するものとする。

この時、config = YAML.load("config.yaml") みたいに
専用のクラスを作らない場合は、

log_file = config["log_file"] || DEFAULT_LOG_FILE
みたいなコードを阿智事に書かないといけなくなる

MyConfigみたいなものを作っていれば、

log_file = my_config.log_file とするだけで良くなる。

**デフォルトの名無しさん** · 2017/08/21(月) 12:51:37.97

> みたいなコードを阿智事に書かないといけなくなる
なんだこれｗ「あちこち」な

**デフォルトの名無しさん** · 2017/08/21(月) 13:03:59.99

また別の話として、設定ファイルに

log_file = 任意のファイル名

という風にログファイル名が書かれている場合はログに出力するが、
何も書かれていなければ出力しないという仕様だったとする。

ある時、ファイル名は書いているが一時的に無効にしたいという要望がでたため

log_enabled = true
log_file = 任意のファイル名

以下のような仕様に変えたとする
（MySQL の general_log = 0 で無効になるのと同じような仕様だな）

この場合専用のクラスがなければあちこちで、

if log_file を if log_enabled && log_file みたいに書き換えないといけない。
だけど専用のクラスがあれば、内部で吸収できる

設定ファイルに log_enabled が書いていなくても、デフォルト値をtrueにすることなんて簡単だし
log_enabledがtrueの場合だけ、log_fileを返すようにすることで、今までと互換性を保つことができる。

それだけじゃない。設定値を返すのではなく専用の設定クラスから直接Loggerオブジェクトを
返すようにすれば、NullLogger（つまり何も出力しないログクラス）を作ることで、
if log_file 自体も無くすことができる

アプリの中にある、あらゆる "設定ファイルの解釈" を設定クラス自身にさせることで
アプリからは単純な設定として参照できるようになるんだよ

**デフォルトの名無しさん** · 2017/08/21(月) 13:17:27.75

あと容易に思いつくだろうけど、
専用のクラスがあれば、設定ファイルをXMLからYAMLに変えることだって簡単にできる
単に内部のファイル形式が変わるだけで、クラスのインターフェースは変わらないからね。

それから設定ファイルの構造を変えるのも簡単になる。
例えばもともとini形式で
[DATA]
file_0_title = "ファイル0"
file_0_path = "/path/to/file0"
file_1_title = "ファイル1"
file_1_path = "/path/to/file1"

みたいなものを単純にYAML化してこんなことしちゃっても
data:
- file_0_title: ファイル0
- file_0_path: /path/to/file0
- file_1_title: ファイル1
- file_1_path: /path/to/file1

あとからこのように変えることだってできる。
data:
files:
- title: ファイル0
- path: /path/to/file0
- title: ファイル1
- path: /path/to/file1

なぜなら設定クラスのインターフェースはini形式の時代から
設定クラス内で解釈することによって、config.data.files とすることだってできるし、
互換性のために、config.data.file_0_title という参照方法を残すことだってできる。

設定値を単純にハッシュにして参照するのではなく、クラスにラップすることでこういうメリットが有るわけだよ