- PR -

複数フォームで同じコードを書いてあるのですが。

投稿者投稿内容
よねKEN
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2007-06-14 11:22
引用:

れいさんの書き込み (2007-06-14 10:02) より:
引用:

よねKENさんの書き込み (2007-06-14 01:07) より:
#業務上の仕様次第なのでここでは答えはでないでしょう。


ここでみんなで仕様を決めてるわけではなし、締め切りもないですし、
この案件で、答えは必要ない、のではないでしょうか?



一般論ではなく、スレ主の質問に対するベターな方法については、
その業務仕様を把握しないと何ともいえないなぁというのが正直なところです。
みなさんの書かれている案にはどれも一理あると思うので、
ある案に全否定のようなレスが付いているのを見て、
果たして全否定されるような案なのだろうか?と自分なりに考えてみました。

で、途中からスレ主の質問とは離れて、個々の背景を元に
継承したコントロールを作成するかどうか?みたいな話になってきたのですが、
個々の背景(つまりは前提条件)がわからないので、若干会話がかみ合っていない気がします。
そういう意味で「業務上の仕様」の想定を挙げないことには、
それぞれの意見のよしあしを各個人が判断しづらい状況になっていると思います。

>#業務上の仕様次第なのでここでは答えはでないでしょう。

と書いたのはそのためで「答え」と言っているのは、
このスレッドでの個々人の前提と前提に対する発言内容を理解した上で、
個々人がはじき出すベストの答えという意味です。

私としては、前提条件の仕様を提示して、それに対してこのように考えて、
その結果、こんな実装したよと実装例の一つも示せるとよいと思うのですが、
そこまでは手が回らないので・・・(^^;

引用:

よねKENさん:?



スレッドを通しての理解が間違っていなければですが、
元々、じゃんぬねっとさんや囚人さんと同じ意見です。
でも、"内容3"が増えた場合にどうなるか?という話が
囚人さんから出されたときに、私はその意見はベストじゃないのでは?と思いました。

「継承コントロール化」は難しいと思っています。
でも、うまく継承コントロール化できたら、まぁ楽ですよね。
だから、安全に楽できる方法は今も模索しています。

NAL-6295
ぬし
会議室デビュー日: 2003/01/26
投稿数: 966
お住まい・勤務地: 東京
投稿日時: 2007-06-14 11:45
引用:

れいさんの書き込み (2007-06-14 10:02) より:
楽しく読ませてもらってます。

NAL-6295さん:継承コントロールが増えると大変なのでStaticから貼り付け




私の場合は、
データとコントロールは基本的に分離しておいて、
コントロールにバインドするデータの種類や表示の仕方の単位に
目的にあった名前をつけたstaticなメソッドを用意して、
データとコントロールをバインドするようにしています。
昔からある安易な手といえば、それまでなんですが、
実際に使うときは、そのstaticなメソッドを呼ぶだけで良いのと、
どういう目的でバインドしているのかがメソッド名で明確になる
のは利点だと思います。

種類分メソッドを作る事に関しては、
種類分継承するパターンと似ていますね。
内か外かの違いだと思います。
まどか
ぬし
会議室デビュー日: 2005/09/06
投稿数: 372
お住まい・勤務地: ますのすし管区
投稿日時: 2007-06-14 11:45
引用:

指針はないでしょうか?


結局、囚人さんが言われたように「都道府県は別の話」、
つまり、データ(の集合を現す項目)が不変性を持っているかが一つのポイントになるのではないでしょうか。
#都道府県に関しては「一つ選ぶ」という目的にも不変性が見えます。
そのへんが明らかになると、より問題に直結した返答が得られるのではと思います。

元々直接書かれているようですのでデータは外部に保持していないと解釈します。
その背景を前提にすると、変更時にどうするんだということを気にするのであれば
専用コントロールを考えるのであればデータを外部で保持することも同時に考えるべきかなとも思います。
#内部で抽象化してもアプリの入れ替えは変わらないわけで。
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2007-06-14 11:58
都道府県を扱うときに内部ではコードで扱う(01:北海道 02:青森県…)という前提で話をしますが、都道府県はそうそう変わらないからといって、コードと値の対の定義をドロップダウンリストの中に含めてしまっていいものでしょうか。
例えばあるデータの「住所(都道府県)」の値として"04"という値(岩手県の意味)が入っていたとします。そのデータを帳票に出したいという場合にはどうしますか。コードに対応する名前はやはり別の場所に定義しておく必要があるんじゃないでしょうか。それはプログラム内の定数かもしれませんし、データベースの都道府県マスタかもしれません。
そうすると、ドロップダウンリスト内でも同じ定義をするよりは、そのどこかにある定義を使う方が良いと思います。

都道府県を扱うカスタムコントロールを作るの自体は問題ないと思います。
私だったらこうするかな。カスタムコントロールを使う例ではありませんけど。
コード:
public class Form1 : Form
{
	private void Form1_Load(object sender, EventArgs e)
	{
		//コンボボックス初期化
		ComboBoxInitializer.SetTodoufuken(comboBox1, false);

	}
}

public static class ComboBoxInitializer
{
	public static void SetTodoufuken(ComboBox target, bool addNull)
	{
		//データベースなどからデータを取得しtargetに設定		
	}

	public static void SetShicyouson(ComboBox target, string todoufuken, bool addNull)
	{
		//データベースなどからデータを取得しtargetに設定	
	}
}


addNullという引数は「選択なし」的な空の項目を含めるかどうかです。その他本州のみ一覧に出すなどの画面で必要な機能はComboBoxInitializerに実装してしまいます。
「データベースなどからデータを取得」する処理は帳票で都道府県名を表示する場合にも使えるような、UIとは関係のないものを想定しています。
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2007-06-14 12:21
引用:

まどかさんの書き込み (2007-06-14 11:45) より:

元々直接書かれているようですのでデータは外部に保持していないと解釈します。


私の最初の返信は、それ自体がほとんどないというか望ましくないという意味合い (前提) で書かせて頂きました。私は最初の質問を拝見してソースに含めていること自体に異を唱えたかったのですが、もうすでに仕様が決まった状態での質問のようでしたから、"まあ今回は値が固定値なので、ここまで書いてしまうとあまりに酷だと思いますが" と添えて書きました。

引用:

つまり、データ(の集合を現す項目)が不変性を持っているかが一つのポイントになるのではないでしょうか。


不変だからという理由でソースに含めて良いという切り分けにはならないですから、あくまで "ひとつの" ですね。たとえば、リレーションで使うパターンではまずいです。私の場合はその予定がなくても外部データストアを使って管理することが多いです。それで困ったことは特にありません。

逆に const メンバに "実データ" を用意することはほとんどありません。再ビルドの手間どうこうの問題ではなく、数も種類も多くなりがちで可読性が悪くなるからです。定数メンバは意味を持つ固定的な値ですから可読性を損ねては元も子もありません。もちろん 「クラス間で解決できるデータ (メタ情報) にも列挙体 (定数メンバ) を使わない」 という意味ではありません。書き方が難しいですが。

引用:

一郎さんの書き込み (2007-06-14 11:58) より:

例えばあるデータの「住所(都道府県)」の値として"04"という値(岩手県の意味)


オフトピですが、JP-04 は 「宮城県」 だったような...

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
れい
ぬし
会議室デビュー日: 2005/11/01
投稿数: 346
投稿日時: 2007-06-14 12:31
引用:

"データを完全に分離できない" の部分に纏わる事情をもう少し詳しくお聞かせ願えないでしょうか?
私は決まりきったかのように意見を書いていますが、正直なところこの手の問題 (メンテナンス性・実装者の分かりやすさ・工数の短縮・切り分け) に悩むコトが多いです。



じゃんぬさん、みなさんに申し訳ないですが、
みなさんの役に立てるような話はできません。

ただの与太話ならできます。
非常に長いんで、付き合ってくれる方だけお読みください。

データに対し操作、ロジックを為すところのプログラムも、HDD上のデータ、
つまり、データですよね?
すべてのロジックは、データであらわせるわけです。
つまり、データは「いわゆるデータ」と「ロジック」の2つあって、
「いわゆるデータ」はしょっちゅう変わる。
発注がある度とか、WEBアクセスする度とか。
ロジックのほうは、あまり変わらない「データ」。
Windowsアップデートの時とか、たまに変わるだけ。

そうみると、所詮ロジックもデータで、
線引きは「どのくらいの頻度で変わるか」に過ぎないと。
どのくらいの頻度で変わるものをデータとするのか、
それは大きな悩みの一つなわけで、
「データを完全に分離する」という大原則だけをいわれると、
ロジックも全てデータですから、データとして扱ってしまえ、
ということになってしまいませんか?

LISPの世界ですね。

実際、.Netでは実行時に文字列をプログラムとしてコンパイル可能ですので、
いろいろ不思議なことができます。
以下のような実装可能なアプリを考えました。

引用:

フォームに、テキスト入力が可能なコンボボックスが一つ、ボタンが一つ。

コンボボックスに文字列を入れてボタンを押すと、
コンボボックスに入った文字列をドロップダウンリストに保存。
さらにその文字列をコンパイルして実行する。

これだけで、全てのロジックが実装可能。
DB接続も、HTTPブラウジングも、年金払込確認も、理論的には可能。

ドロップダウンリストはよく使う順、変更しない順にソートする。
よく使う文字列(プログラミング)は上のほうに、
よく更新する文字列、変更する文字列は下のほうに来る。

よく使う文字列は、定期的にDLLにコンパイルされて、
アプリケーションからコンパイルせずに呼ばれるようになる。
しばらく使わないとDLLから削除さる。



さて、どこがロジックでどこがデータでしょうか?
同じアプリを二つ用意して「互いが互いを更新しあう」とすると、
もうデータとロジックの区別は完全にありません。

で、このプログラムは応用できます。
ある架空の費用算出ソフトを考えます。携帯の料金とか。
先方の要望が、
「この費用の計算式は時と場合と対象によって変わる」
「その計算式自体は今後変わる可能性がある」
「変わる頻度はわからないが、変更のための追加費用は出さない」
だった場合、みなさんはどうしますか?

ここで私はロジックを内臓したデータベースを用いました。
データベースに、「時 場合 対象 計算式」を並べて、
これをデータとし、じゃんぬさんの言うように、コンボボックスに流し、
「時 場合 対象」の一覧を出しました。
コンボボックスで選んで計算ボタンを押すと、
計算式をJavaScriptで計算して結果を費用として計算するようにしました。
(当時は.Net無かったんで、JavaScriptが楽でした。)

もちろん、計算式データベースを変更するためのプログラムも作って、
計算式が変わった際の変更は先方に任せます。
「JavaScriptは勉強してください」と言って。
これで不定期に無料で呼び出されることもなくなります。

私の作ったのは、プログラムなんでしょうか?プログラムを作るためのプログラム?
計算式データベースに入っているのは、プログラムですか?データですか?

まぁなにはともあれ、私はこの「先方にやらせる」方法が大好きです。
無茶な要求をしてきた相手に、合理的且つ経済的に「自分でやれ」と言えるので。
ですが、じゃんぬさんの「データを完全に分離する」よりも二つほどメタっていまして、
「ロジックまで分離」しちゃってます。
メタな世界に行けば行くほど開発に時間がかかりますので、
暇なときにどうぞ。

徹夜したせいか、暴走気味で後悔してます。
長文失礼しました。

れい
ぬし
会議室デビュー日: 2005/11/01
投稿数: 346
投稿日時: 2007-06-14 13:01

駄文を書いてる間に書込みがたくさん。
みなさんどうもありがとうございます。
スレ主を押しのけてる感があり申し訳ないです。

引用:

よねKENさん:
一般論ではなく、スレ主の質問に対するベターな方法については、
その業務仕様を把握しないと何ともいえないなぁというのが正直なところです。



はい。スレ主の質問にたいして、ベターな方法はたぶん言えないと思ったので、
では、ベターな方法を考える方法を教えてあげられないかと。
(いやむしろ私に教えてください、と。)

引用:

NAL-6295さんの書き込み (2007-06-14 11:45) より:



NAL-6295さんの書込みは(以前のも含め)私にはすごくわかりやすいです。
なぜそう思ったか、が明確に書かれていて、関心します。
staticが増えちゃいそうな方法ですが…。

私は継承コントロールを使ってデータをいじったことはほとんど無いです。
ほぼ全部じゃんぬ流で、都道府県もバインドしてました。
もしかしたら埼玉県が東京都に合併されるかもしれないのですし。

場合によっては囚人さんやよねKENさんの継承コントロールは説得力があるんですが、
やはりまず一番に気にするのは不変性なようですね。

引用:

不変だからという理由でソースに含めて良いという切り分けにはならないですから、あくまで "ひとつの" ですね。たとえば、リレーションで使うパターンではまずいです。私の場合はその予定がなくても外部データストアを使って管理することが多いです。それで困ったことは特にありません。



普遍であってもリレーションでつながれてる場合はデータストア行き。
いちいち都道府県情報をDBから読むということですか。

1 不変性
2 他のデータとの連携

ということらしいですよ>スレ主
えムナウ
大ベテラン
会議室デビュー日: 2004/06/10
投稿数: 187
お住まい・勤務地: 東京
投稿日時: 2007-06-14 15:04
れいさん。

>えムナウさん:?
?マークをつけられてしまいました。

このケースの場合ですが。

>ビジネスロジックありのデータとみなす。
>データのまとまりをクラス化する。
>クラスにコンボボックスに流すメソッドを持つ。
この方針なのです。

>所詮ロジックもデータ
その通りなんですが。
それを言ったら
所詮その辺にあるものと同じ元素の集まりで出来ている
私たちが楽しく議論しているわけですから。

たとえばMVCパターンで言うと、
モデルとして扱うのかビューの一部なのかという話ですね。

私はモデルとして扱う方がいいと思っています。

ただ、カスタムコントロール化するかどうかについては、
初心者活用の面や自分自身が楽をするために配置するだけで動作するものも
あっていいんじゃないかと思っています。

_________________
えムナウ Microsoft MVP for Visual Developer - C#,2005/01-2007/12
えムナウのプログラミングのページ Blog1 Blog2

[ メッセージ編集済み 編集者: えムナウ 編集日時 2007-06-14 15:49 ]

スキルアップ/キャリアアップ(JOB@IT)