現代的なプログラミングで、価格表のようなものはどのように表現するものなのでしょうか。

そもそもデータ処理の実装でDBなしとか、二次元配列以外の回答が無いと思うんだが。

単純な2次元データをクラスにするとかオブジェクトにするとか無駄の極みだし、
変更を楽にするにはDBを使用するべきだろうし。

infograveさん、ありがとうございます。
うーんそうなるとローカルデータベースとかってことになるんでしょうかね。。。

二次元データを連想配列の二次元表にして、引数を列挙型にして…なども試してみましたが、記述量が膨大になって変更管理が大変になりそうでしたし、確かに無駄ですよね。

確かに最近はSQLiteなんて物も有り手軽にDBを扱うことができるので、単純な表としてデータを扱う程度ならクラスなんかを定義せず素直にDBを使った方が良いかもしれませんね。

まぁそれもデータ量によると思いますが。
「出発と到着の都道府県により価格が決まる」となると47^2パターンかな？

supermomongaさん、ありがとうございます。

やっぱりローカルデータベースに持つのがいいのかなぁ。
データ量についてですが、価格表以外にもいろいろ係数などがあるのでかなり数は多いです。

>価格表クラスを定義するとして、どういうクラスを作るのでしょうか。

価格表の仕様によって異なります。

例えば価格が出発地と到着地さえ解れば計算式で算出できる場合、計算アルゴリズムを組み込んだメソッドを実装するなどすれば、わざわざ全通りの価格をデータとして保持させるよりはスマートですね。
まぁ今回の例では計算できる類の物ではないと思いますが。
他には、「速達の場合は＋200円」の様な条件付けを仕様として追加したい時などは、クラスを定義して置いた方が遥かに良いです。

最初の実装は面倒でも、堅牢性・メンテナンス性など、型定義のメリットは大きいと思いますよ。


>『価格表オブジェクト.get価格( 出発都道府県 , 到着都道府県)』
>といったようなメソッドを定義するようなイメージでしょうか。
>実装の隠蔽、引数が文字列でも内部で変換が可能、間違った文字列「例：土佐県」などを引数に与えた場合のエラーチェックが可能、などがメリットでしょうか

そうですね、アクセサ含めカプセル化は重要です。

また、「単純な2次元データをクラスにするとかオブジェクトにするとか無駄の極み」というコメントもありましたが、必ずしもそうとは言えません。
例えばもし「AからBへの送料とBからAへの送料は同じ」という仕様なのであれば、データを47^2パターン定義するのは無駄です。
単純に「A-B間の料金」をデータとして定義しそのデータへアクセスする仕組みをクラスで実装してやればいいのですが、2次元配列だとそうはいきませんね。
また価格が変動した場合もAからB・BからAと2ヶ所の価格を書き換えなければいけないといったデメリットもあります。

このように、データの振る舞いを考えて実装するというのが良いでしょう。


>データ量についてですが、価格表以外にもいろいろ係数などがあるのでかなり数は多いです。
大量のデータをこねくり回すのであれば、それこそDBを使うのが「現代的」な気がします。
分析関数なんかをちゃんと覚えればかなり高度なデータ操作もできますよ。

> データ量についてですが、価格表以外にもいろいろ係数などがあるのでかなり数は多い
> ローカルデータベース

supermomonga さんと同じで、DBを使うのが「現代的」だと思うのですが、
C#であれば、価格計算をクラス化してデータはMSXMLライブラリでXMLから構造で持ってくるとか。