設定ファイルを読み書きする時は専用のクラスを作れ [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
よっぽど小さいプログラムでない限り
YAMLやJSONなどを読み込んでハッシュにしたものを参照するのではなく
設定ファイルクラスを作ってアクセスするべきである
理由は拡張性や互換性を保ってシンプルに使えるようにするため これは誰も反対するやついないわ
つかわざわざ自作しなくても標準でそういう機能が用意されてるか
一般的によく使われてるライブラリがあると思うぞ xmlを使ってたけど
でかくなると文字列処理だから
超おっそいぜ >>1
この程度の処理大事にするほどのもんかなぁ?
dobon貼れば終わるんだろ? 読み込みクソ重いのに
20msに一回とか言われっと
速度ベースで考えないと駄目なときも >>4
> つかわざわざ自作しなくても標準でそういう機能が用意されてるか
> 一般的によく使われてるライブラリがあると思うぞ
いや違う。そういう話じゃない。
例えばApacheであればApache専用の設定クラスを作るということ
そして自作のMyAppであればMyAppConfigという専用のクラスを作るということ ケースバイケースじゃん
そもそもどこに持つんだよ?
ってのと
通信設定なのかログ設定なのか
製品設定なのか表示設定なのか
ユーザ毎の設定なんてデータベースだし
あの場合はこの場合は?
ってすべてを包括できるもんはできんと思うがどうか? >>10
だからこそ、その違いをクラスで吸収するんだよ
もし専用のクラスがなかったら、その設定項目を利用するたびに
ファイルから取得しようかデータベースから取得しようか
考えないといけなくなるだろ 例えば、ある設定値を取得する場合を考える。
具体的にログのファイル名とするか?
設定ファイルで設定している場合は、そのファイル名
そうでなければ /tmp/myapp.log に出力するものとする。
この時、config = YAML.load("config.yaml") みたいに
専用のクラスを作らない場合は、
log_file = config["log_file"] || DEFAULT_LOG_FILE
みたいなコードを阿智事に書かないといけなくなる
MyConfigみたいなものを作っていれば、
log_file = my_config.log_file とするだけで良くなる。 > みたいなコードを阿智事に書かないといけなくなる
なんだこれw 「あちこち」な また別の話として、設定ファイルに
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 自体も無くすことができる
アプリの中にある、あらゆる "設定ファイルの解釈" を設定クラス自身にさせることで
アプリからは単純な設定として参照できるようになるんだよ あと容易に思いつくだろうけど、
専用のクラスがあれば、設定ファイルを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 という参照方法を残すことだってできる。
設定値を単純にハッシュにして参照するのではなく、クラスにラップすることでこういうメリットが有るわけだよ >>8
RailsならRails configuration object
設定管理を一箇所にまとめるのは至極当然のこと
一箇所にまとめずに
log_file = config["log_file"] || DEFAULT_LOG_FILEとかif log_fileとか
そういうのをあちこちに書いてるほうが普通じゃないよ >>15
ここだけそうじゃ無くしたい
に弱そう(´・ω・`) 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
2215S ■ このスレッドは過去ログ倉庫に格納されています