C♯相談室 Part30

なぜフォーム上のコントロールのイベントがすべてフォームクラスに記述されるんでしょうか？
それぞれのイベントはそれぞれのコントロールで処理したほうがいいように思うんですが
コントロールが増えてくるとそれをすべてフォームクラスで中継して
データを参照したり受け渡ししたり変換したり、表示するように命令したりなどしなければならないのがすごく煩わしいです

>イベントはそれぞれのコントロールで処理したほうがいい

意味が分からん

>>713
そうしたきゃそうすればいいよ。
絶対今よりも煩わしく複雑になるけど。

MVCは原理主義

>>713
UserControlがあるだろ。
設計とかそんなん自分で頭働かせて煩わしくないようにすればいい

>>713
もしかしてFlashのActionScriptあたりの影響受けてるのか？
あの糞実装は現在「推奨されない記述方法」となっていてActionScript用のレイヤにまとめて書くことが推奨されてるぞ

どっかのレスにもあったが、処理の責任区分を明確にしてないからそういう糞発想が出るんだよ。
ボタンは一般的には「ユーザインタフェースとしてボタンを押すという入力を受け取る」機能が目的なんだから、その上位に対して「ボタンが押されたこと」を通知するのが責任区分
ボタンが押されたことに対してどう処理するかをボタンに責任持たせるべきだと思うか？
・・・まあ、思うからそうユーザ視点で処理を書いているんだろうな
開発者の癖にユーザ視点というのはデザイナー出身FlashActionScript屋っぽい発想だな

処理のレイヤを分割するのは今時の設計では基礎の基礎だと思う
ユーザ視点で処理を実装しているとそのうち破綻するぞ

ファイルダイアログに処理全部かくことにしました。

まだプログラミング初めて1ヶ月程度なんでそんな大そうな人間はありません

ボタンが押される→DATAを読み込む→DATAをテキスト形式に変換→テキストボックスに表示
　　　　　　　　　　　　　　　↓
　　　　　　　　　　　　データを一覧できるようにリストに追加

この一連の作業をFormクラスで記述するのがどうもまどろっこしいんです。
小規模ならいいんですが、徐々に複雑になっていくとFormクラスがメソッドだらけになりそうで
パーティアルとかで分散クラスにすることもできるようですがしっくりきません。
なので、ボタンが押されたら、FormにRead("ファイル名");だけを記述すれば全部やってくれるようにしたかった
できれば、わざわざFormにイベント送ってくるんじゃなくてボタンクラスで処理できればと思ったり
ファイルを読み込むクラスと変換するクラスなどそれぞれ作っても
ファイルクラスにファイル名を送るのも、DATAをテキストに変換するクラスのメソッドにDATAを渡すのも
そのDATAをtextboxに渡すのもすべてFormクラスで記述するのって混乱しませんか？
って、発想から来てます。

>>720
Formにイベント送ってくるんじゃなくてボタンにイベント送ってくるんだけど。
Formに記述してるメソッドをボタンのイベントに登録してるだけ。

好きなとこにメソッド書いて登録すればいいと思うよ。

>>720　混乱するとかはよくわからんが･･･何かするときに誰が何の責任を謳歌で考えればいいと思うよ。

>>720
そんなに複雑なら、データ入出力クラス作っちゃえ。
すれば Form から分離することが出来る。


ところでパーティアルじゃなくてパーシャル。

Visual C# 2005 Express Edition を使用しています。
プロジェクト内のすべての.csファイルを一括印刷する方法はありますでしょうか。

読めてないなぁ俺。下のほう完全に重複してるじゃん。

>>720
フォームは、自分にボタンとテキストボックスが乗っかってることを知ってるよな？
じゃあ、ボタンは、自分が載っているフォームにテキストボックスがあることを知ってるべきなのか？とか。
処理を仲介するものを１つ定義するとしたら、Form あたりが適切になってくると思うが。

>>721
ボタンなどのコントロールはFormクラスでインスタンス化されたオブジェクトだから
外部のクラスからは他のクラスのオブジェクトは直接操作できないですよね？
いや、コントロールをすべてpublicにしてしまえばいけますけど、よくないですよね？
だから、好きなとこにメソッド書いてもアクセス権が無ければ意味がないわけで
結局、コントロールを配置してるFormクラスですべてのコントロールのデータ受け渡し表示まで
管理しないとダメってことになりますよね？

Formクラス→それぞれのコントロール管理するクラス→コントロールクラス

みたいな構造が理想かな？
管理クラスをFormで宣言して、管理クラス内でコントロールを作成したらいけるんでしょうが
そうなると、グラフィカル（IDEでマウス操作で）にコントロールのプロパティや外見を作成できず、
すべてコードで記入しないといけないですよね？
>>720のような一連の作業の橋渡しをするようなクラスを実現したいんです

別クラスにスりゃいいだろ

>>726　そのフォームでやる内容がほかの場合でも使うようなものならば別クラスもいいと思うけれど、
その場合にしかないような処理ならば、そのFormでしてもいいんじゃないか？
要はコントロール郡をまとめる管理クラスをFormがかねてるのが気に食わないんでしょ？

簡単にいうと中央集権型の構造が嫌なんです
コントロール分権型のほうが扱い易くないですか？そうでもないですか？
別クラスと言っても、結局Formクラスにコントロールがある以上は
データの中継はFormクラスを通さないといけないわけで
自分でも何言ってるのかよくわからなくなってきましたがｗ
コントロールの管理はFORMがするのが基本なんですか？

>>728
> 要はコントロール郡をまとめる管理クラスをFormがかねてるのが気に食わないんでしょ？
そうなんです。繰り返し使う関数や処理はできるだけ別クラス作ってますが
クラスが増えれば増えるほど、クラスのメソッド呼び出し、データ受け取りなど増えていきませんか？
今Formクラスのメソッドは呼び出しとデータ受け渡しだらけです。こんなもんなんでしょうか？

んなら UserControl に Button と TextBox をはっつけりゃいいだろ

屋根の上に屋根をつくってほしいって言ってるように見えるが。

>繰り返し使う関数や処理はできるだけ別クラス作ってますが
これが間違いっぽい。

スクロールするのがめんどくさいって話でしょ
そんなん知るか

Formはユーザーに対してインターフェースを提供するだけであって
データの受け渡しなどはしてほしくないんです
そういう内部的な動作は別のクラスに一挙にまかせて
Formはそれぞれのコントロールのイベントを取得して
内部処理クラスにそういうイベントがありましたよってのを通知するだけにしたいんです

>>730
連動させるのがその二つだけの小規模なものならいんですが
大量にコントロールが増えた時のことを考えてください
そうなるとFormの二の舞です

>>731
そうです。C#を実現するために、windows上にframeworkがあるようなもんです

>>732
簡単にいうとそういうことです。
一つ一つのクラスのメソッドはできるだけ少なくしたいんです

>>729　MVCってしってる？デザパタ読め。
同じような繰り返し処理が分離でき再利用されるものなら関数としてであろうがクラスとしてであろうが分離すべし。
まぁ自分はビューとコントローラはそこまで分離させないが。

>>733
プレゼンテーション層であるFormにビジネスロジックなんて載せないだろ
ビジネスロジック用の別クラスを作ってButton→Form→ビジネスロジックのメソッドってやるだろが
自分で勝手にFormを中央集権にしてるんじゃん
だから処理の責任区分が曖昧だっつーの

>>736
もちろんビジネスロジックは別に用意してますよ

何度もいうようにそれぞれのコントロールを中継する役割をFormがやるのが気に食わないんです
×Button→Form→ビジネスロジック
○Button→ビジネスロジック
これならいいんです。すべてのコントロールの中継するためのコードだけでも
大量になりますよね？>>720のような一連の作業をFormを通さないでできますか？
私が言ってるのはそういうことなんです
Formからすべてのコントロールのパブリックメソッドにアクセスできるような状態が嫌なんです

それがいいとは思わんが、そのためにイベントがあるんだと思うが。
ボタンのイベントにビジネスロジックの呼び出しを登録すればよいだけ。

>>733の言ってる内部処理とは関数とかそういうのではなく
中継するためのコードのことです

private textView()
{
　　　string[] data=ファイル入出力クラス.FileOpen("ファイル名");
　　　string[] text=変換処理クラス.ConvertToText(data);
textBox1.Text=text;
}
↑のようなコードをFormクラスで書きますよね？こういうのがウザいんです
たったこれだけならいいですが、コントロールの数だけ、変換処理の種類だけ
大量に書かないといけないわけで、それが嫌なんです

>>713
知らんがな
マイクロソフトに言えや

>>739　じゃ、おまいの理想のコード書いてミーよ。

>>739
好きなクラスに書いたらいいがな

ところで型まちがってるよ

おれは >>738 の意見に賛成だな。

Button1_Click {
　　Text1.Text = Hoge.ReadAndConvert("ファイル名");
}

って感じで。

>>743
そのコードが Form クラスにかかれるのが気に食わないらしいんですよ

>>743
そのイベントドリブンをFormに書くってことですよね？
既に、私のFormはそういう感じです。
ほとんどの処理がイベントドリブン内で収まってます
メソッドやフィールド、プロパティなどはほとんどありません。
でも、コードはだんだんと長くなりFormクラスを圧迫しつつあります
イベント処理をFormに書くことが嫌なんです
Formはほっといてほしいんです

>>745
知らんがな
マイクロソフトに言えや

今週のキーワード

ホームはほっといてほしいんです

はい、続けて

ホームｈ(ry

てことは、

Private Button1_Click() {
　　Controller.Button1_Click();
}

Class Controller {
　　void Button1_Click() {
　　　　// 処理をここに書く
　　}
}

ってやりたいと？ それこそ無駄だと思うなｗ

>>744-745　ちゃうちゃう
必要な処理はManagerクラスにでも書く。
そのイベントドリブン処理が全部マネージャークラスに行く。

Form{
Form(){
button1.Click+=new ButtonEventHandler(controller.DoClick);
}
}
Controller{
void DoClick(){
sukinasyori
}
}

イベントデリゲートを登録するときに Manager クラスに引っ掛ければいいんだろうけど、
IDE のサポートがなくなっちゃうしな・・・

>>746
私はまだC#を熟知したわけじゃありません。
一通りのC#の概要について一読しただけで
これからアプリを作成しようと思っている若輩者です
ここにいる住民の方々なら匠の技を教えて頂けるのではと思い相談に上がった次第です
わたしの言っていることは傲慢なんでしょうか？
一般的なプログラミングとはかけ離れた妄想なんでしょうか？
もしそういうことなら遠慮なくそうおっしゃってください。
一般的にはこうするものだと言っていただければ従います
クラス設計をするに当たってただ単に質問させて頂いただけなんです
不快な気持ちにさせようとしている訳じゃない事をご了承ください

>>752
少なくとも、MS はフォームの責務としてイベントを受け取るところまではやるべき、という考えなんだろ。
IDE はその考えに基づいて作られてるから、あくまで我を通したいというなら IDE のサポートは期待
しないこった。

private void _executeCommandOnButtonXXXClicked(){
textBox.Text = this.LogicController.GetDataText("filename");
}
一行ならだめか？
コントロールの数だけクラス作るほうがめんどくさいと思うんだが。
713の理想のコードってコマンドパターンチックに行く感じ？
class GetDataButton: Button{
　　protected override void OnClick(EventArgs e){
　　　　/**/
　　}
}

>>752
そっちの理想だと、Button と動作が完全に癒着しているけど良いの？
ボタンを押すことと、処理を行うことはそこまで密接に関係があるのか。


とりあえず、悪いとは言わない。色んな方法があるから。

>>753
なるほど、Formにイベントドリブンを記述しないとそうなりますか
IDEを恩恵を捨ててまで初心者がやるべきことではないということですね

>>754
イベント処理をFormで受け取って、イベント処理内容を別クラスに定義するということですよね？
でも結局イベントはFormで受け取っている以上、実際には1行では済まなくなると思います
ファイルが存在しなかったら？ファイル内容が○○だった場合の処理分岐は？など
イベントを受け取る側では実行結果後の分岐処理が待っているんだと思います

やはり、すべてFormでデータの受け渡し、データ入出力要請などをしないとダメっぽいですね
Formコードが長くなったらパーシャル使うなど・・・と言った感じですか。

>>755
クラスはできるだけ隠蔽すべきだってのを呼んでいると、Formクラスから多くのコントロールが見えてしまうのは
あまりよくないんじゃないのか？それだったらコントロールごとに動作と連携させればいいんじゃないか？
そしてデータ構造や動作に関してはFormクラスからは見えないようにしたほうがいいんじゃないのか？って発想なんです
それぞれのコントロールはお互い何をやっているかもわからないし、ただ与えられただけのことをやればいいみたいな感じです
アクセス修飾子に関しても、publicprotectprivateとかじゃなくて、このクラスとだけ入出力できるような特定できればいいんですけど
public(bottun1) Class ボタンの動作//Bottunからだけ見える管理クラス
{
}
みたいな感じですね。こうなると別のネームスペース、プロジェクトを作れということなのかな？

結局どっかには書くことになるから、まとめてあるほうが楽だよ
漏れのお勧めは
Form{
Form(){
button1.Click+=new EventHandler(button1_Clicked);
}
private void button1_Clicked(object sender, EventArgs e){
　　　this.Controller.Execute();
}
}
Controller{
void Execute(){/**/}
}
結果はExecuteの戻り値なりイベントなりで取得。

さらにコントロールが多かったりするとbutton1とロジックを結びつけるコンポーネント作ったりしてるけど
button1.Click += ....のところを
LogicAndViewTieManager.Join(button1, this.Controller.Execute);みたいな

>>756
・・・・・・？　そこまで自分の考えがまとまっているのなら、それでやればいいじゃん。
Button クラス継承して、イベント引っ掛けてデータ処理して・・・・・・ Form 介さずにも何とか出来るよ。

>>757
うまく例えられないですけど、フォルダのサブフォルダのそのまたサブフォルダのって感じで
多段階層に対しての管理はそれでやるとまとめられると思うけど
私がほしいのは横とのつながりなんです。Form上のTextBoxとListViewのデータの受け渡し変換など

>>758
その言葉聞くとなんだか自分の考えがおかしいような気がしてきた
私がやろうとしてるのは
IEでお気に入りのURLをクリックするとHPが開かれる
けれども、URLのボタンにHP内の画像や文字列が格納されてるわけじゃない
HPはHPでサーバーが管理しているわけで・・・
やっぱり、ボタンなどコントロールにデータ管理処理などすべてをやらせるのは
逆に管理が大変になるでしょうね

すべてのメソッドをイベントハンドラとして設計するのはマズイかな？
渡したい値はEventArgs継承型に全部いれちゃって。

個人的にはsenderがオブジェクト型なのでわかり辛いとおもう
Controller内にpublicで定義して、イベントとして登録する使い方ではsenderに依存しちゃいけないと思うし

>>759　だから>>750で結論でてるやん

>>762
別クラスから、FormクラスのtextboxとListviewの両方にはアクセスできませんよ

できるだろ。

>>763　Controllerに両方のポインタ渡しとけばいいだけやん。

dllに分けてinternalプロパティやメソッドで公開

>>713
まずさ、マイクロソフトの提示するやりかたをキッチリ理解してよ
次に開発の一般的な実装方法を学習してよ（デザインパターンとか）
当然の知識が無いのに「オレ流の正しさを理解してくれ」って語られても困るんだよね

>>765
それはかっこ悪いです

>>766
作業効率が悪いです

>>767
学習します

>>768
＞それはかっこ悪いです
ControllerがFormのかわりにコントロールを管理したいんやなかったの？
ポインタも知らんとどないして管理するつもりやねん。
　

protected virtual void OnSizeChanged(EventArgs e)
{
EventHandler handler = base.Events[eventKeySizeChanged] as EventHandler;
if (handler != null)
{
handler(this, e);
}
}

On〜メソッドを追加するたびに似たようなコードを書くのは気持ち悪いので、
この中身をOn〜から汎用的に使える1つのメソッドにまとめられませんか？

まとめりゃいいだろ。
base.Events 使うなら、RaiseEvent メソッドでも作ってそれにイベント識別オブジェクト送れ

>>769
コントロールの参照を渡すなんてかっこ悪いと思います
小規模ならいいですけど
複雑になってくるとどうなりますか？

Controller.メソッド(textbox,listview,ファイル名、データ名、何行目？、、、）
これこそ余計に混乱しますし、無駄な処理です

相手にした俺が馬鹿だった
以後スルーします

んじゃインタフェースつかえ

1回1回渡すわけねーだろが

小規模なのでいいから一回IDE使わないでGUIアプリ作ってみれば色々見えてくるよ。
学習目的なんだからそのくらい経験してみないと。

713は俺サマ仕様考える前に、学ぶべきことがあるはずだ。

バカはJavaでもやっとけ

>>772
そういうときはインタフェイスを使うんだよ。

713はC♯を作った人間達って自分より低脳だと思っているんだろうな

いきなり仕様を「バグですか?」とか聞いてくるやつもいるからな
初めて数週間で仕様のバグを見抜いたら天才だよな

案外同一人物だったりなｗ

713の中の人は.NetFrameworkで定義済みのクラスに
機能追加できるようになるC#3.xまで待てば？:)

言ってることが矛盾してるなあ。
あちこちでいろんなものを管理すると分散するし参照の引き回しがややこしくなるから
すべての持ち主であるFormが管理するようになってるんだと思うがなあ。
いやなら別のクラスに分けるけど、分けた以上は必要な参照は渡さざるを得ないし。

ひょっとしてjavaでWebプログラミングしてた人？

インターフェースは特殊な例に対してのみ使うものではないと思うんです
似通った振る舞いをそれぞれのクラスがする場合に一貫性を保つ位置付けであると考えてます
それにインターフェースを付けたからといって根本的な解決にはなっていないようにも思えます

>>783
おいおい無茶言うな
ちなみに無茶ってのは3.0を待つということじゃなくて解決になってないってことな。

・・・・・・あれかな？　理想を追い求めるばかりに、自分で自分を絞め殺しちゃうような。

>>785
C#が気に入らなければ自分で言語作れば？

>>784
その通りです。参照の引き回しをしたくないから、単純に別クラスにすればいいとか
イベントドリブンを包括するクラスを作ればいいとかそういう問題ではないんですよ

例えば警備会社がここの家を監視しているとして、警備会社の社長がすべての家をモニタするでしょうか？
実際は従業員がそれぞれの家を監視するわけです
Formは言わば社長なんです。それぞれのコンロールを保持しているけれども、管理まではさせたくないんです
あるクラスは、ファイルの入出力からTextBoxに表示するまでを管理して
あるクラスは、TextBoxのデータを元にListViewに表示する
あるクラスは、データの入出力だけを管理する
と言った具合に、管理する業務を分担したいんです
これらをすべてメソッドで書くなんて大変です

あと、プログラミングはまったく初めてです。今までしたことがありません
C#が初めてです。

Form が社長と考えてるからそうなるんだろうなぁ

正直にいうとむかーし、F-BASIC386とHigh C CompilerとQuick Cはやったことがあります
でもその頃は小学生だったのでほとんどまともなことができません
ドラクエのみたいに背景がスクロールしてキャラが動く程度です

誰もあなたの身のうち話なんて知りたくない。
いい加減空気読んで回線切ろうね。

C#だと社長は.NETになるんじゃないかなぁとおもたり。
その下にFormという中間管理職がいるのが妥当では？>例えると

そうですか
では、今日はこの辺にしておきます
また、進展ありましたら報告しにやってきます。
ありがとうございました

進展しないと思う

>>793
そういう話になれば、OSが社長で中間管理職（中間コンパイラ）がFrameworkなわけで・・
そういう次元の話ではないんですよ。あくまで例えですから。

C#でプログラミングする場合にはOSは殆ど見えんだろ

というか 752 で言ってる当初の目的は住人の総反対という結果で満たされたと思うんだが、
それでもなお自説にこだわるってのはどうなんだか。

つ プライド

聞いてもいない自分のことを語り出した時点でダメだこりゃと思った

聞いてはいないですが、何度も以前プログラムしてたのでは？
みたいなことを言われるので言ったまでの話です。
普通の会話だと思いますが、プログラマのみなさんには
命令したこと以外のことが起きると困惑されるみたいですね

なんですって！ｷｰｯ！

>>801の手腕に舌鼓を打った。

>>713
君の心の中を書いてあげるよ

・自分が絶対
・自分が正しいと思ったことは客観的に見ても正しい
・自分が違うと思ったことは客観的に見ても誤っている
・自分の意見を理解できない人々はおかしい人々だ
・だからどうして私の高尚な意見を理解できないんだｸｽﾞ共が

こんなとこだろ
少しは他人の意見に耳を傾けて脊髄反射レスするまえに勉強しろや

>>789
> あるクラスは、ファイルの入出力からTextBoxに表示するまでを管理して
> あるクラスは、TextBoxのデータを元にListViewに表示する

カプリングとコヒージョンからやり直せ。責務の持たせ方がめちゃくちゃ。

> あるクラスは、データの入出力だけを管理する

これはまぁいいけど。

GUI つくるときには、同じ処理をコマンドラインからも行えるように考えながら設計してみるといいよ。
それだけで処理を GUI から切り離して考えられる。

713に対する反論には開発業界が時間をかけて培ってきた定石が多く含まれている
それに対する713の反論は概念と断片的な例だけで具体性が無く「○○だから△△」という対症療法的な稚拙なものばかり

713は脊髄反射する前に反論に含まれる定石を理解すべきだと思うがな
それらの定石が成立するまでには数年に渡る多くの人間の試行錯誤があるわけで、たかが一個人が10日程度試行錯誤したものとは次元が違う

結局Form上に書くのがベストだけど、長くなるからPartial Classを実現させた、
って感じでおｋ？

長くなるからパーシャルなんていってるやつはいないんじゃねえ？
７１３以外は。

>>806
「自分の理解を超えるものは全否定」っていう、厨房天才の典型パターンじゃまいか。

それで自己完結して自己解決しているならどうでもいいけど、こうして語られると鬱陶しいね。

何を言っても「自分の理解を超えるもの」だから、厨反論しかしてこないしね。

>>807
pertial は、IDE のデザイナ側が弄るファイルとプログラマ側が弄るファイルを明確に分離するのが一番の目的。
まあ、長くなるから分けるってのは俺自身やったことあるから何ともいえないけど。

partial だよ…… orz
だめだ。このキーワード自分で打つ機会が少ないから憶えらんない｡･ﾟ･(ﾉД`)･ﾟ･｡

>>811 お前がスレ建てるとPert31になりそうだな

part -> partial か。納得 orz

>>810
ネストクラスで長いの分けて書いたりしてみたけども(Internalに
すればいいんだがもっと厳密にアクセサビリティ追求してみよう
と思って)いまいち使い勝手がよくない。

さらにprojファイルいじってdependentUponなんてしてみたが
結局戻した。

いや、見通しはよくなりはするんだけど。やるまでもないっていうか

>>796
そのたとえなら、Form社長はControl従業員の名簿くらいは持っていて、
いま誰が何の業務でどこに配備されているか把握しておくものだろ。
現場での業務内容は、ビジネスロジックという名の
業務手順書に書いておけばよくて、社長は把握しなくてもいい。
この手順書さえあれば、web新社長が就任してフリーターのsubmit君を
雇ったときにも対応できる。
従業員や職種が増えたらUserControl課長を雇うんだよ。そのとき社長が
把握するのは課長と一部の直属従業員。

Formにビジネスロジックまで書くのはワンマン社長のやることで、
Formにコントロールのイベントハンドラすらないのは放漫経営だ。

概念論しか語らない香具師に概念論を語っても理解してくれない
根本を理解してもらうしかない

曖昧論な例え話禁止

初心者にしてはレベルの高い議題を上げてしまって、みなさんを困惑させてしまったようですね
あれからいろいろ調べたところ、Form1をインスタンス化するクラスとそのクラスを実行する
メインエントリクラスを作ることで分担させることができました
つまり、Form1を包括するクラスとそれを包括するクラスを用意したわけで
これで作業分担できそうです。とりあえず、これでやっていきたいと思います

もう来なくていいよ

古今まれに見るうざさ。ここまでひどいのもめずらしい。

ぜんぶふぉーむくらすのなかに、かくこんとろーるをけいしょうしたくらすをていぎすればいいとおもいまうす

解決法見る限り、どう見ても質問してたこと解決してないし。
もういいや。少しでも手助けしようとした自分が馬鹿だった。

自称で「ぼくはレベルが高い」という初心者には困る。

>>821
もうしてます

>>822
してますよ。包括クラス１はコントロール間の管理、包括2はファイル入出力とデータコレクションクラス間の管理
何度も言ってますが、ビジネスロジックは別に設けています。ここでいう管理はクラスの振る舞いに対する指示だけです

>>818
レベルの低い人間からの常識外れな議題でみんな困惑したんだよ
何言っても理解できないレベルの人に教えるのは本当大変な事なんだよ

>>824
君の脳内結論に非常に興味がある
是非blogかWikiに書いてくれ
ここまで定石ができあがった業界に対して疑問を持ち自分なりの結論を得たというのは興味深い
もしかして定石に一石を投じる結果になるかもしれない
だから今度はオレ達に教えてくれ

私が編み出したこのプログラミング手法をHierarchical Management(階層的管理)志向と名づけます
1つ1つのコントロールは多種多様な振る舞いをするわけで、その振る舞いを一括して支持するのが
Form1クラスだけというのは負担が大きすぎます。
会社の組織に例えるとForm1は直属の上司と言った所でしょうか
その上司にも上司がいるわけで、木の枝のように指示内容も量も広がっていきます
それぞれの節目に管理クラスを設けることで、できるだけ分散させようという試みです。
例えば、あるコントロールの動作を変更したいと思った場合、Form1の数多くあるメソッドの中から
変更に関係あるメソッドを探すのは大変です。管理職と現場はグループ化していればこういう問題は起きません。
みなさんも試してみてください。そうすれば私が言っていることがわかるでしょう。

>>824 オイ、マヂカヨ
俺の言ってることって

class Form1:form {
MyButton1 button1;
MyButton2 button2;
中略
class MyButton1 :Button {
てきとうなしょり
てきとうなOnイベントメソッド
}
class MyButton2 :Button {
てきとうなしょり
てきとうなOnイベントメソッド
}
}

こんなかんじのことっすよ(´･ω･)
こんなんやってるほうが狭軌の沙汰だと思うんだが

>>827 >>713
既にそうなってくるとスレ違いなので
どっかにまとめてきておくれ。ここに書かないで下さい。

>>828
それならそうと最初に言ってください。そういうことはしていません。ダサいです。
今私が議論していることはそんな低次元なことじゃないんですよね・・・。
昔から要領がよくて何でもすぐ出来てしまう私は飽きっぽいんですよ。
私はこの1ヶ月間で実質的なプログラミングはしていません。
C#の概要とオブジェクト志向について学んだだけに過ぎません。
いや、実際のところプログラミングよりそこが重要なんですけどね。
アルゴリズムは多くあれど、プログラミング手法についてはまだまだ
介入できる隙があるようですけどねｗ

解決したってんだからいいじゃん。
もうお触り禁止

途中から釣りなんだろうけど。
CompositeとかDecoratorあたりだろ。
そもそもIDE自体はMicrosoftが想定してるデザインに基づいて動いているだけで他のデザインが間違ってるわけじゃない。
独自のデザインでやるならGUI配置等の恩恵は諦めろ。

まあここまで来るとネタだろうけども
もし本当に何か新しい方法を見つけたと思ってるのなら
どっかにサンプルコードをまとめてくれませんか。
私は馬鹿なので827のように日本語で書かれても
実際どんな実装をしているのか分からないのです。

>連動させるのがその二つだけの小規模なものならいんですが
>大量にコントロールが増えた時のことを考えてください
>そうなるとFormの二の舞です

すいません、このへんの話とどう違うのかわかりません・・・。

まあ折角なので根本に戻って考えると

例えば、テキストボックスの脇に「参照」ってボタンつけて
ボタン押すとファイル選択ダイアログを開く
そしてそのファイル名をテキストボックスに入れる

こんな実装を結構使うわけだけど
確かにこの場合、ボタンは該当するテキストボックスとしか関係しないわけで
このテキストボックスとボタンを綺麗にまとめてカプセル化し、
かつ、いちいち独自のユーザコントロールを作ったり継承したりしないで、
かつ、現在のIDEのGUIと矛盾しない、楽な方法があるなら
俺も知りたい

>>835
私が議論しているのはまさにそれですね。
つまり、Form上でインスタンス化されたオブジェク群は平社員です。
横並びでずらーっと並んでいるわけですよ。それをFormだけが管理するのが
開発効率的にも、そしてクラスを隠蔽するという原因となった人間の誤操作と点でも問題なんですよ。
オブジェクト同士が横と繋がるパイプラインをどう持たせるかが問題なわけです。
ユーザーコントロールというのも手ですが、これは効率がよくありません。
グループ化は動的で柔軟に対応できるようなものでないと意味がありません。
しかし、現在のところIDEが対応していないということなので、Formクラスを包括するクラスをいくつか作り
自制しながらプログラミングするしかないのが現状だということなんです。

>>836
最終的に Control 系は、クラス階層的にも Composite 階層的にも木構造だから。
葉と葉は、直接連絡しあえないんだよね。必ず幹を通らなくては、隣の葉にすら移動できない。

木構造を止めてしまえば直接つなぐことが出来るけど、
管理しにくくなるというデメリットまで許容することが出来るか〜ってのは問題かな。

>>837
すいません。ちょっと語弊がありました。
オブジェクト同士の連携は直接というより、管理クラス（幹）がほしいわけなんです
そうでないと、隠蔽どころか完全なブラックボックスですからね
隠蔽と言っても必要な情報はやりとりしたいわけで。
M$のIDEは木の根から多数の葉が生えているような状態なんですよ
これが非常にうざいんですよね。面倒なだけでできなくはないですが
プログラミングを本職にしている人ならわかると思いますが、できるだけじゃダメですよね？
時間を節約できる効率的なプログラミングを目指しますよね？
ある一連の振る舞いを管理するためだけのクラスがあったら便利と思いませんか？
平社員の連携を保つために、わざわざ社長が指導するんでしょうか？
私が言ってるのはそういうことなんです

>>835
つ component (見えない奴)

参照ボタンなるユーザ定義コンポーネントを作って、それのプロパティに
ボタンとテキストボックスを指定できるようにすればいいんじゃない？

>>836>>837
Panel みたいな見える奴にいれるから階層構造になっちゃうわけで、
単に論理的にまとめ（て機能させ）るだけなら見えないのから参照させて
おけばいい。

具体的に書くと

student.Name
student.学校名
student.クラス名

というのがあってこれをそれぞれのコントロールに渡す処理をするとします

Class Form
{
　public View()
　{
　　　textBox1.Text=student.Name;
　　　comboBox1.Text=student.学校名
　　　listView1.Items.Add(クラス名);
　}
}

どうですか？面倒ですよね？まあ、これぐらいじゃ別に面倒でもないか
しかし、データの種類や量が多くなってきたらどうなりますか？
↓のようなのが理想だと思います

Class Form
{
　public View()
　{
　　　//管理クラスにstudentを渡すことで
　　　//上記のようにそれぞれのコントロールに表示されます
　　　管理クラス(student);
　}
}

>>840 どっちが面倒かっていったら後者じゃね？
実質的な手間は変わらんし

まあ見た目はしらんが

だからそういうのをIDEで簡単にやろうってのが component なんだってば。
Form には形のある Control しか貼れないわけじゃないでそ？

Menu と MenuItem の関係のように、「生徒管理」とかいうコンポーネントを
それのプロパティ textBox に textBox1 を、comboBox に comboBox1 を、
ListView に ListView1 を指定して、データソースなりアレイのプロパティ
なりで student(s) を渡してやればいいんだよ。、

>>838
悪い。管理クラスが欲しいにもかかわらず、その管理クラスを作るのを面倒に思っているように見えた。
UserControl 使って管理クラス作ればいいじゃん。

ちげえよバカ。837だ。

>>840
class 管理クラス : UserControl
{
public 管理クラス(Student student)
{
textBox1.Text=student.Name;
comboBox1.Text=student.学校名
listView1.Items.Add(クラス名);
}
}

社長がどうのとか概念論からコードに話を変えたら粗が見えるな
つか何年前の議論だこれ？

>>845
UserControlは嫌なんですよ。
ファイルダイアログとテキストボックスなど近くに配置して
単純な連動するものならいいですが、
UserControlでは、全体のデザインを変えなくてはダメじゃないですか
デザインにもこだわりたいし、それから、listviewにアクセスするコントロールは別にもあるんです

Aコントロールから、targetコントロールへの連動
Bコントロールから、targetコントロールへの連動

この二つを独立させたいんです。単純に機能がまとまってるなら私もUserControl使ってますよ
それから、話はそれだけじゃないんです。ファイル入出力から表示するまでの一連の動作を管理したいんです

それからcomponentクラスのヘルプが「情報がありません」とかで見れませんでした
ComponentEditorForm クラスのヘルプは見れたので多分同じような機能だとは思いますが
これもユーザーコントロールみたいにコントロールをカプセル化するための機能なんじゃないですか？

> Class Form
> {
> 　public View()
> 　{
> 　　　//管理クラスにstudentを渡すことで
> 　　　//上記のようにそれぞれのコントロールに表示されます
> 　　　管理クラス(student);
> 　}
> }

管理クラスの中で何をやってるのか教えてよ。

>>847
UserControl が嫌なら、管理クラス作ればいいじゃん。何を迷ってるのさ。
それから、管理は一元化するべき。listview に直接アクセスするオブジェクトを２個も３個も作るとややこしくなる。

>>835
コンポーネントじゃだめなの？
Formを経由せずに複数の情報を必要な範囲で連携させる方法って正しくコンポーネントだと思うんだけど
フォームはコントロールのホストって構成ならASP.NETなんてもっと顕著だろ
ノンプログラミング（フォームは構造定義に特化）でblog作ったりできるわけだし、Windows Formでもコンポーネント使えばFormのコードに全く触らずコントロール連携中心の開発もできる
「知らないから実装されていない」って思い込んじゃ駄目だよ

>>847

> これもユーザーコントロールみたいにコントロールをカプセル化するための機能なんじゃないですか？

偉そうな口聞くならさ、自分の中でヘルプ見れば分かるレベルの疑問を解決してからにしてよ
プログラム初めて何日だか知らんが、同じレベルで会話したいんならんな逃げ口上使うなや

>>847
＞それから、話はそれだけじゃないんです。ファイル入出力から表示するまでの一連の動作を管理したいんです 
それまで全部やってくれる管理クラスを、なぜ作ろうとしないのか。

>>713
君のその実装方法で何か作ってよ
外枠ばっかりで具体例が無いからわけわかんない
一つのものを作り上げてそこから見えてくるものもあるだろうし
とりあえず簡単なDB編集ツールでも組み上げて公開してよ
プログラムってのはコントロールだけじゃないんだからデータベースなんかにも対応できるんだよね？

>>847
＞これもユーザーコントロールみたいにコントロールをカプセル化するための機能なんじゃないですか？
合ってる。

というより Form 含め GUI は、ユーザからの入出力のみを担当するべきだと思うんだけどな。
それ以外のデータ処理は別の箇所で行うべきじゃないのかなって。

713のプログラムってコントロール操作だけなんかな

管理クラス作れば？ってまた話がもどりましたね
過去ログぐらい見てくださいよ。

ユーザーを入力によってイベントが発生して、そして一連の動作が発生するわけなんですよ
そのイベントをどこが拾いますか？Formじゃないですか？
一連の動作するクラスをFormから呼び出す場合、その動作に必要なコントロールポインタを
すべて渡さないとだめじゃないですか

何度もいうように

Form→管理クラス→コントロール
　　　　　　　　　　　　→ファイル入出力
　　　　　　　　　　　→データ管理

のような構造が理想だと言っているんです。

>>851
ヘルプがないんだから仕方がありません。

>>856
>そのイベントをどこが拾いますか？Formじゃないですか？ 
Form じゃなくても良いですよ。


>Form→管理クラス→コントロール 
>　　　　　　　　　　　　→ファイル入出力 
>　　　　　　　　　　　→データ管理 
>
>のような構造が理想だと言っているんです。 

だから、その理想に従って管理クラス作ればいいじゃん。
悪いとは言ってない。設計思想は人によって異なるから。

表示のことで言えば、Student クラスにコントロールをバインドする方向で考えるかな。

>>854
もちろんそうですよ。ビジネスロジックはそれようのクラスが担当すればいいだけで
私が言ってるのはデータの橋渡しなんですよ。
コントロールがユーザーからのデータを受け取ってそれでおしまいですか？
違いますよね？そのデータをコレクションクラスに追加しなければならないし
そのデータを元にListviewを更新しなくてはならないわけで
そのような操作をすべてFormクラスがやるのが間違っていると言っているんです
一連の動作はそれようの管理クラスがあるべきです。が、
ユーザーコントロールやコンポーネントではただのコントロールの集約でしかありません。
一連の流れのある振る舞いを管理するものではありません。
もう少し理解力のある人いませんか？何度も同じ説明させないでください。
過去ログみて、それでも意見がある人が答えてくださいよ

>>856
「過去ログ嫁」はみんなが君に対して思っている言葉だよ orz

> ヘルプがないんだから仕方がありません。

んな逃げ口上言うなよ
おれは昔からMSDNだけで勉強して開発してるよ
２ちゃんに書き込めるのにMSDNが見れないなんて馬鹿なこと言わないよな

>>856
＞のような構造が理想だと言っているんです。

713 の目的が聞きたい。とりあえず下から選んでくれ。

[1] 構造が上手に設計できなくて困っている。アドヴァイスが欲しい。
[2] 理想的な形を見つけた。みんなに布教したい。

>>858
つまりデータの中身のある場所の参照を表示コントロールのデータに渡すっていうことですよね？
listviewでデータが削除されれば、参照元のデータも削除されると。それでいい場合もありますよ。
しかし、データを壊されたくない場合はそういう訳には行きません

>>859
＞コントロールがユーザーからのデータを受け取ってそれでおしまいですか？ 
おしまいだよ。それ以上は望んでいない。

>>856　>>750,765で結論でてるんだよ池沼。

>>859
君が書いてることはさ、オブジェクト指向とかデザパタとか色々な手法でとっくに議論されてきた話題だよ。
そしてそれに対する実装も、いくつかは君の言う通りに解決されてる。
でも全てが全て君の言う通りじゃない。
そこは何かと言うと、データの扱いに対する責任区分。
君はユーザサイド（主にプレゼンテーション層）からのデータ整流ばかりを気にしてシステム全体でのデータの流れを見ていない。
そこに対してみんなが違和感を感じてツッコミを入れてくるわけ。

じゃあどうすればみんなと対話ができるかというと、君の理論をまとめてドキュメント化して「これでどうですか」とするしかない。
言ってる範囲が無駄に広くてレスの応酬で片付かないし、お互い断片的な部分しか見れないからまともな対話にならない。
だから君の自論を文章化するなりして明示せよ。
それは新たな開発方法論として人がついてくるかも知れないし、よく見れば既存の方法論の劣化版や旧版に過ぎないかもしれない。
君の脳内の全容を知っているのは君しかいないんだから、それをみんなに「わかりやすく・まぎれなく・必要充分に（ISBN4-526-04317-6のキャッチコピーより引用）」表現してくれ
まともな話はそれからだ。

>>863
ちょっと次元が違いますね
私はコントロールにデータ処理までさせるなんて言ってませんよ
あなたはテキストボックスに入力された文字をListViewにどうやって表示させる気ですか？
わたしはその部分の話をしているんです

>>859
付け加えておく。俺は 713 の設計思想には、大筋で同意しているんだ。
反論しないでくれ。ややこしくなるorz

まぁ大量にレスすると不都合なのスルーされるからとりあえず>>861に答えてもらおうぜ

>>868
[3]みんなが知ってることを、さも自分だけは気付いたように勘違いして皆を見下したい。

>>866
＞あなたはテキストボックスに入力された文字をListViewにどうやって表示させる気ですか？ 
少なくとも、TextBox -> ListView の連結は Form が担当することじゃないし、知っているべきことでもない。

よく考えて。TextBox から入力されたデータは、ListView に伝わらない可能性は？
ListView には TextBox から入力されたデータ以外のものは表示されないの？

>>865
確かにそうですね。抽象的なこと言ってても解決されませんね。
わかりました。ちゃんと私が作成した実データを元に反証して頂く事にしましょう。

なんの為に?

というより 713 がステキすぎるｗ
ここまで話せるのが初心者だとは思えないｗｗ

それ以後、713を見た者はいない・・・・

よくわからんのだけど「管理クラス」ってのは複数あるんかな？
ひとつだと結局Form上で作るのとあんまりかわらんよな

プログラミングなんて知らないユーザーが頭に描いているアプリの構造を
そのまま実現したいんじゃないのか？
それに開発者が振り回されたらたまらん。

香ばしい・・・実に香ばしい。
ぉぃ、君！>>713は何でできているのかね？

713の成分解析結果 :

713の43%は大人の都合で出来ています。
713の31%は鉄の意志で出来ています。
713の14%は時間で出来ています。
713の9%は黒インクで出来ています。
713の2%は勢いで出来ています。
713の1%は血で出来ています。

まともにレスしてる奴は自演じゃないのか？
なんにしてもウザ過ぎる

まちがった。こっちだ。

713[sage]の成分解析結果 :

713[sage]の58%は波動で出来ています。
713[sage]の37%はやましさで出来ています。
713[sage]の2%はやらしさで出来ています。
713[sage]の2%は嘘で出来ています。
713[sage]の1%は食塩で出来ています。

>>713
つーか自分でサイトでも立ち上げて
そこに掲示板でもなんでもつくってそこで議論してくれ。

>>875
複数あります。そうでなければ分担作業にならないですからね。

たとえば、入力された文字をすべてリストビューに表示するみたいな
閉塞的で単調な労働をさせられるならユーザーコントロールなどで統合しても問題はないでしょう。
しかし、入力された文字が、「ファイルを開く」だったら？「データを参照」だったら？
呼ばれるコントロールも動作も変わってきます。
それをユーザーコントロールだけで管理するんですか？

ファイルを開くだったら、ファイルを開いて、ListViewItems形式に変換してlistviewに表示する
データ参照だったら、格納されているデータを読み出し表示する

こういったことに柔軟に対応させるには、コントロールの統合だけじゃ役不足なんです。
入力された文字から木の枝のように伸び分かれる一連の動作をそれぞれ管理する場合
Formクラスの上のメソッドのような、管理権限が平等でだらだらと書き記したコード群は綺麗だとは言えません
管理クラスとは一連の動作を柔軟に対応するだけでなく、管理権限の優劣をつけるものでもあります
何度も言うように、Formクラスを社長というなら、管理クラスは直属の上司です。
社長いうことは絶対ですが、通常は直属の上司が平社員の動作を監視します。
PublicやPrivateなどのアクセス権だけでなく、管理権限にも優劣をつけるべきだと思います
1つのアプリケーションを複数の人が作成する場合のことを考えてください。
関数的なクラスの分担だけでなく、ある一定の権限をも持つべきだとは思いませんか？
それをFormとコントロールとの関係へと修正させたいわけなんです。

まあ、のちのち、私が作成したソースをみなさんに提出しますから
そのときにご意見あれば言ってください。

>>882
＞複数あります。そうでなければ分担作業にならないですからね。 
これが間違い。

こないだ似た様なスレみたなぁ

正直HTML + CSS でデザインするのいやなんですけど
ttp://pc8.2ch.net/test/read.cgi/hp/1018053359/

お前らこの池沼によく付き合ってられルナ。出来れば別スレ立ててそっちでやってくれ。
スレが汚れる8。

>>882
オブジェクト指向勉強したらまたおいで。待ってるから。

それ以後、713を見た者はいない・・・・

>>713
悪いけど別にスレ立ててそっちでやってくれない？
幸いマジレスする人もいるみたいだしさ

・・・自演じゃないよねｗ

しつも〜ん。RegexOptionsのECMAScriptって、どんな意味があるの？

>>889

正規表現のオプション
http://msdn2.microsoft.com/ja-jp/library/yd1hzczs(VS.80).aspx
> 式に対して ECMAScript 互換の動作が有効になるように指定します。

あとどんな説明がいるんだ？

>>890
ようするに、ECMAScriptの正規表現エンジン互換で動かすってことなんですか？

良スレだったのにな……。

>>850
Component使えばできるのか…知らなかったよ
と思ってMSDNとか色々見たけどイマイチつかめないなあ…
もし数行のコードで済むようなら、835に書いた内容をどなたかComponent使って
書いてみていただけませんか。

こういうのはどの板にも居ます。
為替のスレで両建てまんせーなやつはもっと香ばしかった。

デザインパターン以前の質問でもうしわけないんですが、

public sealed class Singleton
{
private static Singleton instance = new Singleton();
private Singleton()
{
}
public static Singleton Instance
{
get { return instance; }
set { instance = value; }
}


２度目以降の参照では、
get 以前を飛ばす理由が判りません　＞＜
ご存知の方おねがいします

日本語でおｋ

get以前てどこ？

シングルトンのインスタンス取得プロパティに set てどうよ。

ほんまや、わろた。

public sealed class Singleton 
{ 
    public static readonly Singleton Instance = new Singleton(); 
    private Singleton() {}
}

これで十分

895です
デバッガでステップしていて気が付いたんですが、
飛ばされた部分があるのでおかしいなと思い質問しました
それと、インスタンスの有無をどこで判断したのかも
わかりません

>>901
static メンバが何時どんなときに初期化されるのか考えると良いよ。

>>901
こことか読んだ？
ttps://www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/ImpSingletonInCsharp.asp

>>713
そんなことよりオブジェクト指向とかアーキテクチャとかデザインパターンとかアジャイル開発とかテスト駆動とか
その辺に興味を示せ。
そんな質問どうでもよくなるから。

アプリを作る場合、思いつきで作っていると
とんでもないミスを犯していたり、あとで修正を加えたくなることがよくあります
結局、作り直したりやる気が無くなってしまったりするので
まず、始めにどのようにクラス設計を建てるかを考えなければと思うのですが
こういうときに便利なソフトはないでしょうか？
フローチャートみたいに大まかな流れを書き出したて、作る時の参考にしたいんですけれども
また、ほかに何か良い方法があるなら教えてください

>>905
>こういうときに便利なソフトはないでしょうか？
Visual Studio

VS.NETのリファクタリング機能使って
作り変え時のコストを抑えるようにすればいいと質問の内容を無視してカキコ。

中身空のクラス先に作ってXMLDOCで出力とか。

便利なソフトなど使わなくても思いつきでつくりさえしなければそんなことにはならない。

>>905
最初に適当に書いたソースを眺めて反省しながら設計する。

>>905
>とんでもないミスを犯していたり、あとで修正を加えたくなることがよくあります
>結局、作り直したりやる気が無くなってしまったりするので

最初から完璧なコードなど書けるわけないだろ、
なんでミスを見つけたり修正することに対してネガティブなの？

１．下書きとしてとにかく動くものを作ってから全体を見直して完成度をあげる。
２．机上で完璧な設計をおこなってからプログラムを書き始める。
チーム作業でなければ完成度や開発効率で２の方が優れてるなんてことはない。
個人で作るアプリなら１の方が絶対楽しいし、結果的にいいソフトが作れるはずだ。

>>905
ヒント　次につくるときのこやしとすること

>>905　UMLお絵かきソフト

絵を描く場合にまず、構図を考えるんですね
それをもとに作成していったほうが効率がいいんですが
プログラミングは実際に粘土をこねるような？
いじりながら徐々に目的のものを作り上げていく
そういう感じと捕らえていいんですか？

それにしても、フローチャート書くことがそんなにいけないことなのか？

>>913
いや、だからVS2005持ってるんならソリューションエクスプローラあたりで
右クリックしてクラスダイアグラムの作成、とかやってみれ。当然コードとも
同期してくれる。Pro以上の機能？かも知れないが。

ちなみにフローチャートがいけないって誰が言った？そっちはWorkflow Foundation
あたりを調べてみれ

>>913
フローチャートを描くのがほんとに好きならフローチャートから入ればいいよ。
要はどのようにしてモチベーションを保つかってことが大事。
プログラミングを始めた頃は何でもかんでも面白いけど知識だけで
ものを作り上げる喜びがなければ数年もしないうちに飽きて嫌になってくる。

それと今はプログラミングツールが便利になって開発効率があがったけど
そのぶんドキュメント化されてないノウハウや落とし穴も大幅に増えている。
プログラミングに上達しようと思ったらデッサン力と同時にツールに対する経験と洞察力が不可欠。
そんなわけで粘土をこねるような作業を避けては通れない。

>>713のように知識だけでプログラムを解ったつもりになってると
実際に何か作りはじめた段階でくじけてしまいかねない。

>>915
どうもためになるお話ありがとうございます
実戦してその結果に対して考察しながら知識と経験を高めていく。
物作りの原点を忘れていました。
ライト兄弟の時代、推力や揚力など飛ぶ原理など知らなくても
空を飛びたいという情熱で作り上げていたことを思い浮かべました
飛ぶことができて初めて、なぜ飛べたのか、より遠くへ飛ぶにはどうすればいいか
まず作ってから、考察をするべきだと言えますね

ちなみにわたしは>713ですｗ

オブジェクト指向うんぬんを言う前に、構造化設計の技法を確認したほうがよさげ。
それから、きっちりオブジェクト指向のお勉強だな。

「クラスの設計が・・・」なんていうのは十年早いと見た。

オブジェクト指向は理解してます
今勉強しているのはGRASPとリファクタリングです

アホが嬉々としてわきそうなレスだな

すごいな。UML も知らずに「オブジェクト指向は理解してます」なんていい切れるのか。

んで>>713たんは何を作ろうとしてんの?
後学のために教えて♪

本職は3Dグラフィックデザイナーをやっています。
いわゆる、みなさんと同じデジタル土方ですね。
使用しているソフト用の補助的なツールを開発しようと思って
プログラミングを勉強してみようと思いました。
ソフト付属のマクロ程度なら組むこともできるんですが、それだけでは物足りなくなったわけです

フローチャート風のダイアグラムは、世間一般では全部まとめてフローチャートといわれたりするからな。
俺の書いたユースケースやアクティビティ、ステートチャートも全部まとめてフローチャートと呼ばれちゃってるよ。

>いわゆる、みなさんと同じデジタル土方ですね。
ななななんですってー！キィーツ！

ﾜﾛﾀw

＞オブジェクト指向は理解してます
＞ソフト付属のマクロ程度なら組むこともできる
むむむー

いいから別スレ作れ。713の質問にみんなが答えるスレとか。

713=905だよな？ウザすぎる。あの自己中っぷりは学生だからだと
思っていたんだが、デザイナだったのね。

そのままコンピュータの前で閉じこもっていてほしい

トリップないし中の人って複数人いるのかなあと思ったり。

デジタルひじかた？ＣＧ合成か？

>>916
>ちなみにわたしは>713ですｗ
なんかそんな気がしたんだよね。

>>713って理解力はあるのに惜しいなと思ってたんだが、
別に頭が固いわけじゃなくて思いついたことを率直に言うタイプだったんですね。

優秀なプログラマになれそうな気がする、頑張って下さい。

いいかげんにしてくれ

じゃあ、703=905=932ってことで一件落着！暴れはっちゃく！

まちがえっちった。

ListViewの項目のフォーカスが変更されたときに発生するイベントってある？
項目選択の変更はSelectedIndexChangedでわかるけど、
Ctrlを押しながらカーソルキーを押してフォーカスする項目を変更したときは
どのイベントで通知されるんだろう。

C#のオブジェクト指向は一子相伝のようですが
習得は大変ですか？がんばればケンシロウになれますか？

>>936
ないっぽいね。
親フォームで LVN_ITEMCHANGED を捕まえるくらいか。

>>938
レスありがとう。
ラベルの編集は開始と終了別で教えてくれるのに、
より基本的な変更は簡単にいかないのな。

>>713 = 905
なんかオブジェクト指向を理解した気になってるようだが
そんな簡単に理解できるほど浅いモノではない。
ポリモーフィズムとかインヘリタンスとかの意味をちょちょいっと調べて、オブジェクト指向をわかった気になってるとかそんなだろうな。

つーか

＞アプリを作る場合、思いつきで作っていると
＞とんでもないミスを犯していたり、あとで修正を加えたくなることがよくあります
＞結局、作り直したりやる気が無くなってしまったりするので

とか言ってる時点でオブジェクト指向の入り口すら、全くもってわかってない。

あとリファクタリングはテスト駆動開発で用いる手法であって、単体テストありきだから。
君みたいな素人には早いんじゃない？

nunitの使い方がよくわからない・・・ぐふぅ〜ｗ

>>940
おまえしつこいな
もうええやろ

713の間違いｗ
やっぱ、地道にプログラミングに慣れていくしかないかな

>>940
オブジェクト指向？たくさん本読んだからわかったよ
実践はまだしてないけどね

てか、私のプログラミングのミスとオブジェクト志向への理解との相関関係がわからないのに
なぜそういうことを言えるのか不思議です。超能力者かな？
ただ、ポリモーフィズムって言いたかっただけじゃないんかと・・
ま、知識はついたからあとは実践だね。

今までの経験上、独学をやる場合の教訓は

・知識と経験のバランス
・独断と偏見は捨て先人達を敬う

だな。ま、応援してくれていると受け取っておくよ。

>>943
キミは自分以外が目立つのが気に食わないだけじゃないのかと

誰かココID付にしてくれ。うざす。

>>945
>自分以外が目立つのが気に食わないだけじゃないのかと

あんたは目立ちたいの？だったらただの荒らしだな。
いや・・・そうじゃなくて、みんなが使う掲示板なんだから
自分専用みたいな使い方はどうかと。
どうしてもというのなら新たなスレを作るなり、
自分のHPへ誘導するなりしたらどうですか？

>>947
目立ちたいとも言っていないし
自分専用という根拠について教えてくださいな

私の発言に対して返答してたのはあなた達ですよ
私が独り言のように黙々とメモ帳のようにレスしていたのなら
私物化と言ってもいいかもしれませんけどね。
それにスレ違いの内容でもないですからね。
それより、自分専用のスレを立てるように誘導するほうがどうかしてると思います
ちゃんと2chの規約読みましたか？2ch初心者さんですか？
あなたの意見は見当違いです。

あとは>>947が一番ウザい存在だという自覚を持ってくれることを祈るのみだな。

＞ちなみにわたしは>713ですｗ

この一文は何か意味あったん？　
目立ちたい以外に

あぼーんしやすいように。

関西弁を使う約1名が必死に噛み付いてるのはなぜ？

>>948　これから713は713としてかきこんでくれ。おまいが言ってるように。
ほかの人は出来るだけ相手にしないでください。スレ汚されるのが我慢ならん。

>>937
ジャギ止まり。

いや、ここまでくるとネタだろ
とりあえずスルー推奨
&相手する奴も嵐

Hashtableでkeyの値を上書きするのは
Hashtable[key] = 値ですが、
以下の文だと、実行時に
foreachが抜ける辺りで
InvalidOperationExceptionが
発生してしまいます。
ご存じの方、原因をご教示下さい。

//ハッシュテーブルの全ての値をkey値の2倍にする。
　public static Hashtable TestHash()
　　 {
　　　　Hashtable h = new Hashtable();
　　　　h.Add(1, 0);
　　　　h.Add(2, 0);
　　　　h.Add(3, 0);
　　　　foreach (int i in h.Keys)
　　　　{
　　　　　h[i] = i * 2;
　　　　}
　　　　return h;
　　　}

原因は例外メッセージに書いてるとおりだが。

foreachの取り出し元の変数に変更加えちゃいけないんだっけか？
そのような処理したい場合はいったん配列にキーコピーとかかしら？

つーことでこれでうごいたぽいけど、いい方法かどうかはしらん

Hashtable h = new Hashtable();
h.Add(1, 0);
h.Add(2, 0);
h.Add(3, 0);
int[] a = new int[h.Count];
h.Keys.CopyTo(a, 0);
foreach (int i in a)
{
Console.WriteLine("{0}, {1}", i, h[i]);
h[i] = i * 2;
}

>>958-959
ありがとうございます。

foreach のループ対象はkeyの値ですし、
実際に取り出したkey値を操作するのではなく、
ハッシュリストの値の方を編集するわけですし・・・

実際のコードは、以下の様に、編集後のレコードを
もう一つ別に作成したHashtableに入れて、返しています。
キーをコピーした方法も試してみます。
Hashtable h = new Hashtable();
Hashtable rh = new Hashtable();
h.Add("a", 1);
h.Add("b", 2);
h.Add("c", 3);

foreach (string key in h.Keys)
{
　 rh.Add(key,(int)h[key] * 2);
}
return rh;

LVN_ITEMCHANGEDの定義を調べてみたんだが、
こんなのや
#define GVN_SELCHANGED LVN_ITEMCHANGED
こんなの
#define LVN_FIRST ((UINT)-100)
#define LVN_ITEMCHANGED (LVN_FIRST-1)
しか見つからない。
ダメもとでm.Msg == checked((uint)-0x100-1)なんてのも試した。
ローカルの.NET関連のフォルダも見たけどだめ。
WndProcをフォームとリストビューそれぞれに置いてメッセージを調べてみたが、
項目のフォーカスが変更されたときに発行されるものがないような。
それとも>>938は、項目のフォーカスが変更される可能性のある操作を
すべて受け取れって意味だったのかな。

あ、そこから解説必要だった？
**N_*** ってメッセージは NotifyMessage って言われるもんで、WM_NOTIFY で親フォームに送られる。
WM_NOTIFY を受け取った場合、LPARAM を NMHDR 構造体にキャストして code メンバでどのメッセージなのか確認する。
// これに関しては unsafe でポインタ使った方が凄い楽。
で、pnmhdr->code == LVN_ITEMCHANGED のときにあれこれする。
ちなみに、WM_NOTIFY は親フォームに流れるけど、
.NET では親フォームはそのコントロール自身にも (WM_REFLECT + WM_NOTIFY) を改めて送信するので、
コントロール自身でも判断可能だ。

713の降臨まだぁ？

今APIについて猛勉強中
資料が少ないから大変だけど、おもしろいねこれ
てか、選ぶ言語間違えたかな。C++のほうがいいみたい

>>705
うーん、以下のコードだと呼ばれないんですが。
適当なFormの中のコードです。
Formに配置されたボタンを押すとgcButton_Clickが呼ばれると思ってください。

private Button testButton = null;
private void gcButton_Click(object sender, EventArgs e) {
　if (testButton == null) {
　　testButton = new Button();
　　testButton.Disposed += new EventHandler(testButton_Disposed);
　　Controls.Add(testButton);
　} else {
　　Controls.Remove(testButton);
　　testButton = null;
　　GC.Collect(); //<- ここでGCしてもtestButton_Disposed()が呼ばれない
　}
}
void testButton_Disposed(object sender, EventArgs e) {
　Debug.WriteLine("button disposed.");
}

GC.Collect() したら GC されるって保障されてんだっけ？

うっわぁ、ほんとに713降臨しやがった＾＾；
君うざすぎｗ
C++の方がいいって思うんだったらC++に乗り換えなよ
そんでもうC#には関わらないで＾＾





っていうと、今更乗り換えられないとか、途中で投げ出したくないとか、C#をちゃんと覚えてからとか言うんだろうね
そんでここのスレにいつまでもまとわりつくと。

1回目はファイナライズキューに入り次のGCで破棄される

>>965
いわゆるデストラクタってのはファイナライザのこと。
ファイナライザはオブジェクトが削除されるときに呼び出される。
で、Disposed イベントは Dispose() メソッドが呼ばれたときに発生する。
Dispose() とファイナライザは直接は関係ないよ。
Disposed を発生させたいなら明示的に Dispose() を呼び出さないと。

っていうかぁ、ファイナライズではイベントハンドラなんて呼ばれないと思うんですけどぉ。

あう、時間差で…
>>970は>>965あてなの

>>970
じゃあ>>391は嘘なのかな？
IDisposeを実装してるオブジェクトはDispose()はプログラムで明示的に呼び出せと？
ちなみにボタンを動的にControls.Add()したままの状態でFormを閉じるとDisposeが呼ばれます。

確かデストラクタはFinalizeメソッドに変換されるんだよな。

IDisposable実装クラスのファイナライザは、通常Dispose(false)を呼び出すように設計しなければならない。
んで、実際System.Windows.Forms.Buttonクラスの基本クラスであるSystem.ComponentModel.ComponentクラスのFinalizeの中身を
覗いてみると、ちゃんとDispose(false)を呼び出している。
ちなみにDispose(bool disposing)メソッドの中でイベントもちゃんと呼ぶようになってるぞ。
だからGCがButtonクラスの回収をすればイベントは発生するはずということ。

んで、GC.Collectっていうのはガベージコレクタを即実行するわけだが、
ガベージコレクタってのは世代管理を行っていて引数を指定しないでGC.Collectを呼び出した場合は
メモリがやばくない限り1世代目の回収しかしない（あとここで世代移動が行われる気がした）。だから必ずしもButtonオブジェクトがGCに回収されるとは限らないわけだ。

つまり、GC.Collect(3)ってやればOKだと思う。

もしかしたら多少違ってるかもしれんから、一度自分でGCについてちゃんと調べることをお勧めしとくよ。

>>972
なんで嘘になるのさ。
Disposed イベントなんて所詮ただのイベント。オブジェクトの掃除とは何の関係もない。
IDisposable は Dispose() が呼ばれなかったら最終的にファイナライザが Dispose(false) を呼び出す。
Dispose(false) は Disposed を発生させないってだけの話。

>>973
Dispose(false) の場合は Disposed を発生させない。
ファイナライザでは参照型のメンバにアクセスしちゃ駄目だから。
もちろんイベントの実体もデリゲートインスタンスなのでファイナライザではさわれない。
さらに、GC.Collect() は全世代のオブジェクトに対して GC を行うとリファレンスに明記されてる。

>>975
すまん、至る所で勘違いが混じってたな。首吊ってくるorz

>>972に突っ込もうと思ったけど>>975がみんな書いてくれた…

>>975
理解しました！
動的ボタンを直接Buttonクラスを使わず以下のように継承してMyButtonを定義し、
overrideしたDisposeメソッドはきちんと呼ばれました。
　private class MyButton : Button {
　　protected override void Dispose(bool disposing) {
　　　Debug.WriteLine("button disposed." + disposing);
　　　base.Dispose(disposing);
　　}
　}
MyButton testButton = null;

＞覗いてみると、ちゃんとDispose(false)を呼び出している。
＞ちなみにDispose(bool disposing)メソッドの中でイベントもちゃんと呼ぶようになってるぞ。
ここまで見といてなんでその際の条件を見ないｗ

GC.WaitForPendingFinalizersも呼んでおくと幸せになれそう。
とチラシの裏。

>>962
丁寧な解説どうもありがとう。
LVN_ITEMCHANGEDの定義の
#define LVN_FIRST (0U-100U)
#define LVN_ITEMCHANGED (LVN_FIRST-1)
が0xffffff9bなんだろうということもやっとわかった。
ただ、LVN_ITEMCHANGEDどころかまずWM_NOTIFYが送られてこないような。
if( m.Msg == 0x004e ){ ... } //こんな感じでスタンバってる
フォーカス移動を知りたいだけなのになんでunsafeとか使わにゃいかんのだ、Gates。

＞GC.WaitForPendingFinalizersも呼んでおくと幸せになれそう。
なんですと？

>>981
WM_NOTIFY は親フォームに送られるって点は OK ？　コントロール自身が待ってない？
ていうかここにかいてあった
ttp://hongliang.seesaa.net/article/16550502.html

MSのコードは適当なタイミングでGC.Collectとか
GC.WaitForPendingFinalizersとか呼んでるね

968が正解

MenuStripを持つ子ウインドウをそのメニューから
this.Close()で閉じるとObjectDisposedExceptionが発生するんですが
ただしい娘ウインドウの終了の仕方ってどんなんでしょう?

いまテストしてみたんですが、

ToolStripMenuItemの
DropDownItemClickedイベントでthis.Close()で閉じると例外、

サブメニューそのもののClickイベントで閉じれば例外が起きません。
こっちでやれってことですかね

微妙に意味が取りづらいが、発生しないよ？

えーとですね、
子フォームにMenuStripをくっつけて、最初のアイテムを"ファイル”として、
そのサブアイテムを”閉じる”とします。

”ファイル”のDropDownItemClickedでthis.Close();を呼ぶと例外、
"閉じる"のClickでthis.Close()なら普通に閉じる。

うちでは100%再現するんですが、(VS2005Express)
とりあえず下の方法でお茶を濁しました……

>>989　自分はそういう自分のせいでない(と思いたい)例外が出るときは、めんどくさいのでイレギュラーな手でお茶を濁す。まぁ全体に影響しない範囲でだが。
この場合なら別スレッドにhandleわたしてPostMessageすると思う。

いや、それは当然だろ。
さあサブメニューを表示しようって時にいきなり親が Dispose されるんだから。
なんで DropDownItemClicked で this.Close なんだよ。

>>991
ああ、そういうことですか。

"DropDownした先のItemをClicked"じゃなくて
"DropDownするItemをClicked"って意味だったんですか。

あんまり腑に落ちませんが
ありがとうございました。

うお、１０００ギリギリでも埋めに入らねぇ。

つか新スレ立ててくれ新スレ。私は無理だったし。
スレタイの♯は半角だと消えるから全角でな。Shift+3 は別の文字だから「しゃーぷ」を変換するんだ。
ていうかコピーすればいいな。

んじゃ建てるよ？

C♯相談室 Part31
http://pc8.2ch.net/test/read.cgi/tech/1145075577/

ksk

乙＆梅

Vistaはよせい

　　　　　　　　　　次スレ以降、>>713は書き込み禁止

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。