Windows Formsで１つのpartial classの中のコードが長いときの対処法

総合スコア28660

2019/05/21 02:27

すみません、書いてあることが何一つ理解できませんので、ちゃんとするのはまた今度にします。ひとまずファイルが長くなりすぎたときに皆さんがどうしているのか、教えていただきたいです。

2019/05/21 02:31

ユーザーコートロールやコンポーネントに分割するという手もあります。

2019/05/21 02:58

ユーザーコートロールを使ったやり方、凄くよさそうです。直感的でわかりやすいです。今までその存在すら知りませんでした。ありがとうございます！

m.ts10806

2019/05/21 03:14

質問者さんすごーーくざっくり要約すると「役割分担」です。画面を表示とイベントやリクエストを受け取って処理する部分は、階層や段階が違うので、わけましょう、ということですね。共通化できそうであればパラメータ渡して中で分岐させたり部品化させていくのも有用です

2019/05/21 05:33

ご回答ありがとうございます。その役割の違いがいまいちわかっていないのかもしれませんが、意識できるように頑張ってみます。

m.ts10806

2019/05/21 05:35

最初から細かく分ける必要はないのでとりあえず「画面描画部分」と「イベントなどの処理部分」からわけてみては。

2019/05/21 05:51

わかりました、ありがとうございます！

2019/05/21 06:14 編集

画面と内部の分離を考えるのであれば、 C# ではデータバインディングが最初の一歩です。これは一言で言えば「データと画面をイベントで結びつける技術」です。例えばテキストボックスに文字が入っているかどうかで背景の色を変えるのであれば、まず string 型の Text プロパティと Color 型の BackColor プロパティを持つオブジェクトを設計します。そのオブジェクトは、Text プロパティの値によって BackColor プロパティの値が変化します。次にこれの BackColor プロパティと TextBox の BackColor プロパティをバインド(連動するよう結びつけること)し、Text プロパティと TextBox の TextBox プロパティをバインドします。これにより、テキストボックスのテキストが変化すると、そのオブジェクトの Text プロパティも連動して変化し、それによって BackColor プロパティも変化します。それに連動してテキストボックスの BackColor プロパティも変化し、背景色が変わることになります。これによって「文字数で背景色を変える」というロジックをフォームから分離し、再利用性を高めます。分離はされましたが、フォームのデザイナーやソースを見ると、そのオブジェクトとテキストボックスがバインドされていることがわかるので、処理の流れを見失うことはありません。いや、むしろ「背景色を変える」という処理を全体の処理の流れから切り離すことにより、見通しを良くすることができます。

2019/05/21 06:17

文字の長さと背景色の処理だけでこのようにクラスを設計するのは大げさかもしれませんが、この技術は様々に応用がきくので、ぜひ積極的に取り入れてください。「データバインディング」というキーワードです。

2019/05/21 06:23

ただし WPF のデータバインディングと Windows フォームのデータバインディングは全く様子が違うので、それらを混同しないよう、検索の際は気をつけてください。

行動規範の内容に同意します

こんにちは。

「巨大クラス＝悪」ではないと思いますよ。肥大化したクラスはよろしくないですが、必要最小限のクラスが巨大になった場合、「必要最小限」が妥当ならそれは妥当です。GUIクラスの場合、フレームワーク上の制約があるのでなかなかクラス分割も困難ですから。
partialクラスを使ってファイル分割して視認性を保つのも良い工夫と思います。

GUIを司るクラスがあまりに大きくなるようなら、MVCの考え方を導入するのもありと思います。これは機能分割のための１指標ですので。（デザイナーがいないプロジェクトにMVCを適用するのはどうかとも思いますが、MVCは結構メジャーですのでGUIクラスの分割指標として使ってみるのも手と思います。）

投稿2019/05/21 03:39

Chironian

総合スコア23272

2019/05/21 05:15

ご回答ありがとうございます。MVCというのも初めて聞きましたが、ざっと読んでみました。MVCでわけてみることも考えてみます。

行動規範の内容に同意します

部品化や構造化などしっかり設計すればいいのでしょうが

手っ取り早くというのであれば

C#
1#region ある処理
2#endregion

で折りたためるようにするとか

投稿2019/05/21 03:29

YAmaGNZ

総合スコア10258

2019/05/21 05:08

折りたたむこともできたんですね……。確かにこれが一番手っ取り早いかもしれません。どうせ見るのは自分だけですし。

行動規範の内容に同意します

ボタンごとにイベントハンドラを作ってるのでそれで数が増える、というのであれば、
ボタンのクリックイベントを全部一つのメソッドにしてしまって、引数のSenderによってどのボタンかを判断してそれで処理を分ける、ってことをすればいいです
同様に、ラベルやTextBoxなんかにもこのテが使えます

投稿2019/05/21 02:59

総合スコア87774

2019/05/21 05:07

ご回答ありがとうございます。その手段は知っていましたが、それでも長くなってしまいました。

2019/05/21 05:23

ということは、実際の処理をFormクラスの中で記述してるんですね。なら、Formのイベントメソッドには処理のメソッド呼び出しのみにして、実際の処理は別クラスにしてしまうってことでいいんでは。FormクラスはGUIの操作関係のみを残すようにすればそれほど肥大化はしないですね

2019/05/21 05:39

そうです、Formクラスの中で全部処理しています。例えばですが、テキストボックスの処理で、TextChangedイベントを発生させたときに、文字が変わったらテキストボックスの背景色を変えるとして、たった１行の処理のためだけにクラスを分けて『ClassB.chgWord(TextBox1);』といった感じに外のクラスに投げるほうがいいのでしょうか？それはそれで処理を見失いそうになるので、今まではしていませんでしたが……。

2019/05/21 05:41

書いてて気づきましたが、自分にとってはこの『処理の流れを見失う』ということが一番の原因で、ファイルをわけるのをためらっていたふしがあります。逆に言うと、一連の流れごとでまとまってくれていればいいので、Zuishinさんに教えていただいたユーザーコントロールを使うやり方が、自分にはひとまず一番理解しやすいやり方だなと思いました。しばらくこのやり方で視認性を高めていこうと思います。

2019/05/21 05:46

いや、GUI画面に関わることはFormに残して、他の処理、例えばファイルから読み込むとかデータベースを操作とかの実際の処理を他に切り出します他の処理から、GUIに表示する、とか色を変える、とかはプロパティやメソッドにしてしまい、画面に関わることとその他を切り分けて実装するってことで、まあ、他の回答者さんと言ってることは一緒ですが

2019/05/21 05:53

理解できていないのかもしれませんが、やってみます。ありがとうございました。