ソースが汚いっ・・・ので分割したいです

環境/言語:[C#　.NETFramework1.1]
分類:[.NET]

C#でコードを組んでいるのですが、Form1.csに関数がぶわーーーっと並んで
1000行近くになってしまいました。
ソースの見通しをよくするために関数を別のファイルに移したいのですが、
自分のレベルに合ったVisualC#の本(入門書)には書いてありません。
検索してもキーワードが悪いのか出てきません。
具体的にはどういうふうにやるのでしょうか？
それとも出来ないのでしょうか？
やりたいことはC言語で言うexternを使ってファイル分割です。

■No17231に返信(やきそばソースさんの記事)
> C#でコードを組んでいるのですが、Form1.csに関数がぶわーーーっと並んで
> 1000行近くになってしまいました。
> ソースの見通しをよくするために関数を別のファイルに移したいのですが、
> 自分のレベルに合ったVisualC#の本(入門書)には書いてありません。
> 検索してもキーワードが悪いのか出てきません。
> 具体的にはどういうふうにやるのでしょうか？
> それとも出来ないのでしょうか？
> やりたいことはC言語で言うexternを使ってファイル分割です。
・大量に定義しているのが「関数」なら、他の.csや.vbとかプログラムコードを書けるファイルを用意させて、
　publicで公開すればいいかもしれませんね

・そうではなくオブジェクトにたいおうする「メソッド」なら、そのままでいいかと

('A`)　ソースを分断させる理由が弱いと思うが…
　　　　ところでC#ってOOPのC++/javaのどちらかというとjavaを引き継いでいるのだろうか
　　　　(メンバ関数とメソッドって意味が微妙に違うことが最近わかった(orz

> やりたいことはC言語で言うexternを使ってファイル分割です。

残念ながらFramework2.0からPartial Classというクラスファイル分割機能が追加されました。
それに伴い新規で作ったフォームでは、1.1でいう「デザイナで生成されたコード」が
Form.Designer.csという別ファイルに生成されるようになりました。

私は、ガッさんの意見に同意なので補足します。

■No17232に返信(ガッさんの記事)
> ・大量に定義しているのが「関数」なら、他の.csや.vbとかプログラムコードを書けるファイルを用意させて、
> 　publicで公開すればいいかもしれませんね

構造化言語的にはこれで良いでしょうね。
問題は関数ではなく、メソッドであるという点だと思います。

> ・そうではなくオブジェクトにたいおうする「メソッド」なら、そのままでいいかと

これで汚く見えるとなると、クラス設計が正しくなされていないということになります。

> ところでC#ってOOPのC++/javaのどちらかというとjavaを引き継いでいるのだろうか

私は、Java に近いと思います。
Java に Delphi のコンポーネント主義なのをドッキングしたような形だと思います。
Windows Form で Form を中心に見るとむしろ Delphi に近いイメージを最近持っています。

# 汚いという理由で Partial クラスが使われてしまうのを、2.0 発売前から危惧しています。
# これでは、机の上の汚いものを引き出しに入れただけで、きれいになったと勘違いしているモノグサと変わらないと思います。
# ちょっと不適切なメタファかな...

ソースが汚いと言うよりソースが長すぎてどこに何を書いたのかを
探すのが大変なんですよ。
とある本には優れたソースの一例としてLinux(だったはず)のコード
を引き合いに出して200行にも達しないくらいのコードでほとんどが
占められてるような事が書いてあったような記憶があるので・・・。
同じ処理をするなら関数化して関数呼び出しで終わるようにするまで
は理解したのですがそこで詰まった・・・って状態です。

新しい項目の追加＞クラスで新しいファイル作成＞
クラス内にstatic publicにしてやって実現できました。
ありがとうございました。

あれ、あの関数はどこのファイルに書いてたっけ？

> あれ、あの関数はどこのファイルに書いてたっけ？
ってならないようにファイル名は分かりやすくつけます。

スクロールバーの位置で関数探すか、ファイル名で関数探すか、
それだけしか変わらないじゃんって言われたらその通りですけど・・・。

横槍ですが
Hongliangさんは名前空間でまとめることをおっしゃってるのでは？

個人的には

> > あれ、あの関数はどこのファイルに書いてたっけ？
> ってならないようにファイル名は分かりやすくつけます。

が出来るのであれば、s/ファイル名/メソッド名/ でFAの気もしますが。
スクロールバーの位置で探さなくても、エディタ画面の上部にメンバ
一覧がコンボボックスで表示されているので、そちらから探すのも
ありです。

あとは region でまとめちゃうとか。

> > ・そうではなくオブジェクトにたいおうする「メソッド」なら、そのままでいいかと
> これで汚く見えるとなると、クラス設計が正しくなされていないということになります。

こういった意見もありますが、クラス設計は　正　し　く　なされていますか？

> 新しい項目の追加＞クラスで新しいファイル作成＞
> クラス内にstatic publicにしてやって実現できました。
> ありがとうございました。
('A`)
個人的な結論を言わせていただければ
・「見辛い」程度を理由にソースをゴチャゴチャしてはイケマセン
です(orz
…ま、泥水を飲んで腹を下せば良い薬になると思うので、存分に飲んでみて欲しいところですが

クラス設計ですか・・・。
まだ学習途上なのでまず”動く”ソースを作ることを考えているので、
全く考慮されていません(滝汗)。
むしろ本を読んでいてクラスで処理すると使用する変数を纏めれば
使いやすくて安全性が高くなるっていう話が理解できていない位低レベル
なので・・・。
関数内で変数宣言してやればスコープで隠蔽できるじゃん　なんでPrivate
とか言って明示的に隠蔽するの？ってまじめに考えるレベルです。

こんにちは。

> まだ学習途上なのでまず”動く”ソースを作ることを考えているので、
> 全く考慮されていません(滝汗)。

これはクラス設計の話が出てきたときに最初に書いておくべきことだったかもしれま
せんね。

> ソースが汚いと言うよりソースが長すぎてどこに何を書いたのかを
> 探すのが大変なんですよ。

このあたりの発言で少しそんな気はしていましたが…

で、ご自分のレベルはある程度自覚されているようなので。
回答者の方々（私含む）には「ソースが汚いので分割」というのを推奨している方は
誰もいないのかなぁと（少なくとも現在までは）。
ではなぜお勧めされないのか、そこはやきそばソースさんが考えるところで、そこを
考えることが技術向上への道なのではないかと思います。

もちろんガッさんの
> …ま、泥水を飲んで腹を下せば良い薬になると思うので、存分に飲んでみて欲しいところですが
には私も大いに賛成ではありますが(笑)。
泥水おいしいですよねー…っておいしいわけあるかーっ！（ノリツッコミ）

ということで考えるきっかけになりそうな先人たちの発言リスト。

>> じゃんぬねっとさん
# 汚いという理由で Partial クラスが使われてしまうのを、2.0 発売前から危惧しています。
# これでは、机の上の汚いものを引き出しに入れただけで、きれいになったと勘違いしているモノグサと変わらないと思います。

>> Hongliangさん
あれ、あの関数はどこのファイルに書いてたっけ？
（ぽぴ王子注：たぶん1ヵ月後ぐらいの想像図と思われる）

>> ガッさん
('A`)　ソースを分断させる理由が弱いと思うが…

>> ぽぴ王子さん（あ、オレだオレ）
あとは region でまとめちゃうとか。


あと、全然関係ないですが
> 関数内で変数宣言してやればスコープで隠蔽できるじゃん　なんでPrivate
> とか言って明示的に隠蔽するの？ってまじめに考えるレベルです。
これが何を意味しているのかわからなかったのですが、説明してもらえますか?

■No17262に返信(ぽぴ王子さんの記事)
> あと、全然関係ないですが
>
> > 関数内で変数宣言してやればスコープで隠蔽できるじゃん　なんでPrivate
> > とか言って明示的に隠蔽するの？ってまじめに考えるレベルです。
>
> これが何を意味しているのかわからなかったのですが、説明してもらえますか?

関数内で変数宣言 ＝ メソッド内のローカル変数 として。

で、Privateというのはメンバ変数（フィールド）を指しているのか、そのローカル変数を含むメソッド自体を指しているのか微妙。

フィールドの場合、クラス内で使うメンバですから、クラスの外部から隠蔽されます。
Privateは大いに効果ありです。ここを何でもかんでもPublic？
クラスの外部からアクセスされるわけでキモいです。

メソッド自体の場合、つーか、ローカル変数はそもそもメソッド内からじゃないとアクセスできないわけです。
だからPrivateなんて意味がない？違う違う。
メソッド自体のアクセスレベルなので意味があります。
無意味にクラス外からアクセス可能なメソッドのあるクラスなんてキショいです。

はいこーん様の指摘の通りです。
平たく言うとクラス＝関数の進化版程度にしか考えていないからです。
だからC#だとMain()が何でクラスに入ってるんだろうって思う位レベルが
低いのです。

//本物でプログラム組むことが出来ない小学生の時に変な本読んで間違った
理解をしていたと言うことに気が付きました。(;ω;)

■No17273に返信(やきそばソースさんの記事)
> //本物でプログラム組むことが出来ない小学生の時に変な本読んで間違った
> 理解をしていたと言うことに気が付きました。(;ω;)
('A`) 最近wikiが色々と書いてあるので必要そうなのを拾ってきてみた
　　　それぞれ２０分くらい、静かなところでゆっくり読むと面白いかもしれない

wiki:
http://ja.wikipedia.org/wiki/

構造化プログラミング:
http://tinyurl.com/6jel8

オブジェクト指向(非プログラミング):
http://tinyurl.com/jc2zo

オブジェクト指向プログラミング:
http://tinyurl.com/hhtko

オブジェクトモデル化技法(非プログラミング):
http://tinyurl.com/jw4z2

Squeak(Smalltalk 後継?) プロトタイプベース:
http://sumim.no-ip.com:8080/wiki/493

<チラ裏 comment="またまた個人的なこと">
<item id="object oriented">
・オブジェクト指向の処理は{「依頼」(=メッセージ)と「反応」(=リアクション)}(=振る舞い)
　の連鎖で成り立つことができる
</item>
<item id="oo programming / class">
・クラスとは
　・「オブジェクトの設計図」としてのオブジェクトを定義し、
　　在る程度の(オブジェクトの数値程度の)柔軟性を持たせる。
　　クラスにアルゴリズムを書き込み、それを実体化(インスタンス化)させインスタンス(=オブジェクト)を生み出すのが目的
　　　　　　　　　　(クラス)─[インスタンス化]→(インスタンス)
　　　　　　　　　　　　↑　　　　　　　　　　　　　↑
　　どちらもオブジェクト(メッセージを受け取り、リアクションできる)
</item>
<memo>
…まぁ、モノの本に書いて有ることとかなり違う気がします(というか私自身は本を読まない人間です)(汗
</memo>
</チラ裏>

失礼しました

いいサイト紹介をありがとうございます。
会社では気が引けるので家でじっくり読ませていただきます。

//はじめてクラスを作って使ってみました。
関数でも十分処理できるものでもクラスにして使ってみることで
メソッドだ、プロパティだ、っていうのが分かったような気がします。
本には〜の時は〜プロパティを使います〜って事しか書いてなかったので
ああ、あるものを組み合わせてプログラム作るんだ、って漠然としか
理解できていなかったこともあってMSDNに載ってる機能が使えないのは何で?
とか色々詰まったりしたけど実際にクラスを作って使ってみて
ああ、そういうことかって少しだけ分かった気がします。
(非常に分かりやすくクラスの作り方/使い方を開設しているサイトを
見つけることが出来たので・・・。見つからなかったら・・・恐ろしい)