- - PR -
複数フォームで同じコードを書いてあるのですが。
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-06-14 11:22
一般論ではなく、スレ主の質問に対するベターな方法については、 その業務仕様を把握しないと何ともいえないなぁというのが正直なところです。 みなさんの書かれている案にはどれも一理あると思うので、 ある案に全否定のようなレスが付いているのを見て、 果たして全否定されるような案なのだろうか?と自分なりに考えてみました。 で、途中からスレ主の質問とは離れて、個々の背景を元に 継承したコントロールを作成するかどうか?みたいな話になってきたのですが、 個々の背景(つまりは前提条件)がわからないので、若干会話がかみ合っていない気がします。 そういう意味で「業務上の仕様」の想定を挙げないことには、 それぞれの意見のよしあしを各個人が判断しづらい状況になっていると思います。 >#業務上の仕様次第なのでここでは答えはでないでしょう。 と書いたのはそのためで「答え」と言っているのは、 このスレッドでの個々人の前提と前提に対する発言内容を理解した上で、 個々人がはじき出すベストの答えという意味です。 私としては、前提条件の仕様を提示して、それに対してこのように考えて、 その結果、こんな実装したよと実装例の一つも示せるとよいと思うのですが、 そこまでは手が回らないので・・・(^^;
スレッドを通しての理解が間違っていなければですが、 元々、じゃんぬねっとさんや囚人さんと同じ意見です。 でも、"内容3"が増えた場合にどうなるか?という話が 囚人さんから出されたときに、私はその意見はベストじゃないのでは?と思いました。 「継承コントロール化」は難しいと思っています。 でも、うまく継承コントロール化できたら、まぁ楽ですよね。 だから、安全に楽できる方法は今も模索しています。 | ||||||||||||
|
投稿日時: 2007-06-14 11:45
私の場合は、 データとコントロールは基本的に分離しておいて、 コントロールにバインドするデータの種類や表示の仕方の単位に 目的にあった名前をつけたstaticなメソッドを用意して、 データとコントロールをバインドするようにしています。 昔からある安易な手といえば、それまでなんですが、 実際に使うときは、そのstaticなメソッドを呼ぶだけで良いのと、 どういう目的でバインドしているのかがメソッド名で明確になる のは利点だと思います。 種類分メソッドを作る事に関しては、 種類分継承するパターンと似ていますね。 内か外かの違いだと思います。 | ||||||||||||
|
投稿日時: 2007-06-14 11:45
結局、囚人さんが言われたように「都道府県は別の話」、 つまり、データ(の集合を現す項目)が不変性を持っているかが一つのポイントになるのではないでしょうか。 #都道府県に関しては「一つ選ぶ」という目的にも不変性が見えます。 そのへんが明らかになると、より問題に直結した返答が得られるのではと思います。 元々直接書かれているようですのでデータは外部に保持していないと解釈します。 その背景を前提にすると、変更時にどうするんだということを気にするのであれば 専用コントロールを考えるのであればデータを外部で保持することも同時に考えるべきかなとも思います。 #内部で抽象化してもアプリの入れ替えは変わらないわけで。 | ||||||||||||
|
投稿日時: 2007-06-14 11:58
都道府県を扱うときに内部ではコードで扱う(01:北海道 02:青森県…)という前提で話をしますが、都道府県はそうそう変わらないからといって、コードと値の対の定義をドロップダウンリストの中に含めてしまっていいものでしょうか。
例えばあるデータの「住所(都道府県)」の値として"04"という値(岩手県の意味)が入っていたとします。そのデータを帳票に出したいという場合にはどうしますか。コードに対応する名前はやはり別の場所に定義しておく必要があるんじゃないでしょうか。それはプログラム内の定数かもしれませんし、データベースの都道府県マスタかもしれません。 そうすると、ドロップダウンリスト内でも同じ定義をするよりは、そのどこかにある定義を使う方が良いと思います。 都道府県を扱うカスタムコントロールを作るの自体は問題ないと思います。 私だったらこうするかな。カスタムコントロールを使う例ではありませんけど。
addNullという引数は「選択なし」的な空の項目を含めるかどうかです。その他本州のみ一覧に出すなどの画面で必要な機能はComboBoxInitializerに実装してしまいます。 「データベースなどからデータを取得」する処理は帳票で都道府県名を表示する場合にも使えるような、UIとは関係のないものを想定しています。 | ||||||||||||
|
投稿日時: 2007-06-14 12:21
私の最初の返信は、それ自体がほとんどないというか望ましくないという意味合い (前提) で書かせて頂きました。私は最初の質問を拝見してソースに含めていること自体に異を唱えたかったのですが、もうすでに仕様が決まった状態での質問のようでしたから、"まあ今回は値が固定値なので、ここまで書いてしまうとあまりに酷だと思いますが" と添えて書きました。
不変だからという理由でソースに含めて良いという切り分けにはならないですから、あくまで "ひとつの" ですね。たとえば、リレーションで使うパターンではまずいです。私の場合はその予定がなくても外部データストアを使って管理することが多いです。それで困ったことは特にありません。 逆に const メンバに "実データ" を用意することはほとんどありません。再ビルドの手間どうこうの問題ではなく、数も種類も多くなりがちで可読性が悪くなるからです。定数メンバは意味を持つ固定的な値ですから可読性を損ねては元も子もありません。もちろん 「クラス間で解決できるデータ (メタ情報) にも列挙体 (定数メンバ) を使わない」 という意味ではありません。書き方が難しいですが。
オフトピですが、JP-04 は 「宮城県」 だったような... _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2007-06-14 12:31
じゃんぬさん、みなさんに申し訳ないですが、 みなさんの役に立てるような話はできません。 ただの与太話ならできます。 非常に長いんで、付き合ってくれる方だけお読みください。 データに対し操作、ロジックを為すところのプログラムも、HDD上のデータ、 つまり、データですよね? すべてのロジックは、データであらわせるわけです。 つまり、データは「いわゆるデータ」と「ロジック」の2つあって、 「いわゆるデータ」はしょっちゅう変わる。 発注がある度とか、WEBアクセスする度とか。 ロジックのほうは、あまり変わらない「データ」。 Windowsアップデートの時とか、たまに変わるだけ。 そうみると、所詮ロジックもデータで、 線引きは「どのくらいの頻度で変わるか」に過ぎないと。 どのくらいの頻度で変わるものをデータとするのか、 それは大きな悩みの一つなわけで、 「データを完全に分離する」という大原則だけをいわれると、 ロジックも全てデータですから、データとして扱ってしまえ、 ということになってしまいませんか? LISPの世界ですね。 実際、.Netでは実行時に文字列をプログラムとしてコンパイル可能ですので、 いろいろ不思議なことができます。 以下のような実装可能なアプリを考えました。
さて、どこがロジックでどこがデータでしょうか? 同じアプリを二つ用意して「互いが互いを更新しあう」とすると、 もうデータとロジックの区別は完全にありません。 で、このプログラムは応用できます。 ある架空の費用算出ソフトを考えます。携帯の料金とか。 先方の要望が、 「この費用の計算式は時と場合と対象によって変わる」 「その計算式自体は今後変わる可能性がある」 「変わる頻度はわからないが、変更のための追加費用は出さない」 だった場合、みなさんはどうしますか? ここで私はロジックを内臓したデータベースを用いました。 データベースに、「時 場合 対象 計算式」を並べて、 これをデータとし、じゃんぬさんの言うように、コンボボックスに流し、 「時 場合 対象」の一覧を出しました。 コンボボックスで選んで計算ボタンを押すと、 計算式をJavaScriptで計算して結果を費用として計算するようにしました。 (当時は.Net無かったんで、JavaScriptが楽でした。) もちろん、計算式データベースを変更するためのプログラムも作って、 計算式が変わった際の変更は先方に任せます。 「JavaScriptは勉強してください」と言って。 これで不定期に無料で呼び出されることもなくなります。 私の作ったのは、プログラムなんでしょうか?プログラムを作るためのプログラム? 計算式データベースに入っているのは、プログラムですか?データですか? まぁなにはともあれ、私はこの「先方にやらせる」方法が大好きです。 無茶な要求をしてきた相手に、合理的且つ経済的に「自分でやれ」と言えるので。 ですが、じゃんぬさんの「データを完全に分離する」よりも二つほどメタっていまして、 「ロジックまで分離」しちゃってます。 メタな世界に行けば行くほど開発に時間がかかりますので、 暇なときにどうぞ。 徹夜したせいか、暴走気味で後悔してます。 長文失礼しました。 | ||||||||||||
|
投稿日時: 2007-06-14 13:01
駄文を書いてる間に書込みがたくさん。 みなさんどうもありがとうございます。 スレ主を押しのけてる感があり申し訳ないです。
はい。スレ主の質問にたいして、ベターな方法はたぶん言えないと思ったので、 では、ベターな方法を考える方法を教えてあげられないかと。 (いやむしろ私に教えてください、と。)
NAL-6295さんの書込みは(以前のも含め)私にはすごくわかりやすいです。 なぜそう思ったか、が明確に書かれていて、関心します。 staticが増えちゃいそうな方法ですが…。 私は継承コントロールを使ってデータをいじったことはほとんど無いです。 ほぼ全部じゃんぬ流で、都道府県もバインドしてました。 もしかしたら埼玉県が東京都に合併されるかもしれないのですし。 場合によっては囚人さんやよねKENさんの継承コントロールは説得力があるんですが、 やはりまず一番に気にするのは不変性なようですね。
普遍であってもリレーションでつながれてる場合はデータストア行き。 いちいち都道府県情報をDBから読むということですか。 1 不変性 2 他のデータとの連携 ということらしいですよ>スレ主 | ||||||||||||
|
投稿日時: 2007-06-14 15:04
れいさん。
>えムナウさん:? ?マークをつけられてしまいました。 このケースの場合ですが。 >ビジネスロジックありのデータとみなす。 >データのまとまりをクラス化する。 >クラスにコンボボックスに流すメソッドを持つ。 この方針なのです。 >所詮ロジックもデータ その通りなんですが。 それを言ったら 所詮その辺にあるものと同じ元素の集まりで出来ている 私たちが楽しく議論しているわけですから。 たとえばMVCパターンで言うと、 モデルとして扱うのかビューの一部なのかという話ですね。 私はモデルとして扱う方がいいと思っています。 ただ、カスタムコントロール化するかどうかについては、 初心者活用の面や自分自身が楽をするために配置するだけで動作するものも あっていいんじゃないかと思っています。 _________________ えムナウ Microsoft MVP for Visual Developer - C#,2005/01-2007/12 えムナウのプログラミングのページ Blog1 Blog2 [ メッセージ編集済み 編集者: えムナウ 編集日時 2007-06-14 15:49 ] |