皆様　ご助言ありがとうございます。 
オブジェクト関連の本は数冊読んで(眺めて)みたのですが 
分かるような分からないような・・・ 
実際自分で作りたいものを目の前にしてまったく応用できなかったのです。 
アドバイスいただいた事をもとに、もう少し気楽に試してみようと思います。ありがとうございました。

こんにちは。 
 
どのように切り分けるかは、 
そのメソッドやクラスを人に説明することを 
意識しながらコーディングすると、 
適切な切り分けができます。 
 
 
 
例えば、こんな説明を必要とするメソッドがあったとします。 
 
「 
あの人が恋人にプロポーズをして、 
了承を得たので、 
書類にはんこを押して、 
それを役所に届けて、 
式を挙げた。 
」 
 
これは、 
 
1、あの人が恋人にプロポーズをする。 
2、了承を得る。 
3、書類にはんこを押す。 
4、それを役所に届ける。 
5、式を挙げる。 
 
のように区切るとわかりやすいです。 
 
この状態は、 
「5W1Hの要素をひとつだけ含んだ一文で説明できるメソッド」 
と言い換えられます。 
 
また、これらのメソッドがどうしても切り離せない一連の流れであった場合、 
それらを集約した一つの文で言い換えられないかを考えます。 
この例文の場合、 
「あの人が恋人と結婚する」 
で説明できます。 
 
また、例えば 
 
1、プロポーズをする。 
2、事故により記憶喪失、身体不随 
3、伝説の介護士の手により奇跡の生還 
4、式を挙げる。 
 
という状態になった場合、2と3をどうするかを検討します。 
一つの文で現せない場合ものは切り離しの余地があります。 
 
（例えば 
プロポーズ 
話 
式 
＝結婚） 
 
僕はオブジェクト指向のオブジェクトを「もの」と訳すのは完全な誤訳だと思っています。 
これは「概念」であり、 
行動であれ状態であれ、すべての概念は単一の意味と対を成すからです。 
 
まぁつまりは「このメソッドを一言で言うと何なんだ？」と問われ、 
一文で答えられない時、それは切り離せるということです。 
5W1Hはわかりやすさの基本です。

> 小さい方が良いと言うより、やはり適切な粒度というものがあります。 
既存の .NET Framework に用意されたクラスが１つの基準になると思います。 
 
Form クラスとか、TextBox クラスとか、Math クラスとか。 
> クラスが大きくなってしまうとき、 
多分、既存のクラスは思っている以上に大きく、色々な機能が実装されて 
いると思います。速読できる人が1ページ分のイメージを瞬時に把握できる 
ように、ある程度、錬度に応じたコードの把握できる量があると思います。 
あまり小さくまとまり過ぎるのも問題かも？ 
また、クラスで分けることより、関数レベルで整理する方が先ではない 
でしょうか。 
 
引数以外に依存しない、十分にデバッグされた関数は、内部処理を気にせず 
使えます。 
 
クラスビューや、[オブジェクト]コンボボックス[プロシージャ]コンボボックス 
など、特定の関数の先頭にジャンプできるような機能も用意されているわけですし、 
Region で折りたたむことも出来ます。 
それほど困るような状況にはならないと思います。 
 
クラスを利用する側はクラス名を打てば入力候補が出るわけですし、[定義へ飛ぶ]で 
関数の位置に飛べるわけですし。

こんにちは。 
 
>プログラムの内容を全てクラスに分けるのは、かなり難しい事ではないでしょうか?  
そんなことはないと思います。 
全てクラスを使用するという要件は単に標準モジュールを使わないというだけで達成できます。(標準モジュールも広い意味ではクラスですが) 
多分、オブジェクト指向などを意識されて難しく考えていらっしゃるのではないですか？ 
 
>自分には、処理の内容を考えていてもクラスがはっきりと見えてこないのです。 
正攻法でいくならオブジェクト指向設計の勉強をされると良いと思いますが、難しく考えなくても大雑把にクラスを分けておくレベルでまずはいいと思います。後から分けなおすこともできますし。 
ただ、大規模アプリケーションや、企業向けエンタープライズアプリケーションのようになってくると事前の計画が重要になってきますから、もしそのようなものを念頭においているのでしたらお気をつけ下さい。 
 
私がよくやるのは、明らかに分けるべきだと思う機能はクラスを分ける。迷う機能は共通便利クラスに放り込むというものです。そのうち共通便利クラスが肥大化してきたらまたそのとき考えます。こんなやり方大声でおすすめするようなものではありませんが私は今のところうまくやれています。 
 
>クラスが大きくなってしまうとき、クラスシートに記載すると、 
>長くて読みにくいのですが、どのようにすればいいのでしょうか?  
クラスシートとは何でしょうか？Excelか何かで書いたクラスの仕様書みたいなものですか？ 
 
>クラスを小さく分けるのが良いことだとは思うのですが、  
>前述のようにクラス分けがうまくできないのです。  
小さい方が良いと言うより、やはり適切な粒度というものがあります。何が適切かはおっしゃるように難しいです。 
少し前にも書いたように私はこのあたりのことは気にしすぎないほうがいいと思います。どうしても気になる場合はオブジェクト指向設計の勉強をすればすっきりできるでしょう。

>>4 
ありがとうございます。 
リンク見させていただき　納得できました。 
モジュールを使わずにクラスだけでプログラムが出来るのですね。 
ただ、プログラムの内容を全てクラスに分けるのは、かなり難しい事ではないでしょうか? 
自分には、処理の内容を考えていてもクラスがはっきりと見えてこないのです。 
 
もうひとつ教えてください。 
クラスが大きくなってしまうとき、クラスシートに記載すると、長くて読みにくいのですが、どのようにすればいいのでしょうか? 
クラスを小さく分けるのが良いことだとは思うのですが、 
前述のようにクラス分けがうまくできないのです。

>>2 
ありがとうございます。 
SinはMathクラスのメソッドである。 
SinはSharedで宣言されているため、 
dim m as Math 
のように宣言しなくても利用できる 
 
このような理解でいいのでしょうか? 
2番目の理解が自信ないのですが・・・。

>参照設定した上で　A.xxx()とすれば利用できるのですが、こういう方法はいけないのでしょうか?  
OKです。 
が、 
http://homepage1.nifty.com/rucio/main/dotnet/shokyu/standard50.htm 
の「２－５．モジュールを使わない理由」で説明している内容も理解した上で利用されるのであればなお良いと思います。 
 
Mathクラスについてはるしぇさんご指摘の通りです。つまり、ひでとさんの手法とMathクラスは異なります。 
原理的には同じですが実装手法は明らかに違うといっていいでしょう。

Math.Sin(角度*3.14/180) 
で動きました。 
今は名前空間やってますよ。.IO

>Math.Sin(Ang)といった使い方をしていますが、この書き方はクラスのインスタンスを 
>作成しない点で同じ方法かな?と思います。  
コードを右クリックして定義へ移動し、オブジェクトブラウザで確認してください。 
>Public Shared Function Sin(ByVal a As Double) As Double 
Shared 宣言で共有化されています。 
 
Shared についてはヘルプ(MSDN)で確認してください。 
[Shared (Visual Basic)] 
http://msdn.microsoft.com/ja-jp/library/zc2b427x(VS.80).aspx 
モジュールでは宣言せず、インスタンスを必要としないメンバのみ共有化 
されているようです。 
 
Class Math は System の下に居ます。プロジェクトの参照を確認してください。 
System のプロパティを見ると、実体は System.dll であることが分かります。

別にいいんじゃない？よく使う自作関数をまとめるのにdllにしたって。

第6章クラス第51回クラスライブラリの作成を拝見させていただきました。 
 
拝見する前に良く分からないまま、 
クラスを含まない(クラスモジュールを削除して)、Public Module Module1 を作成し、そこにPublic Sub xxx() を作ってコンパイルしてみたのですが、それでもdllファイル(A.dll)が作られます。 
それを使用するには　参照設定した上で　A.xxx()とすれば利用できるのですが、こういう方法はいけないのでしょうか? 
 
VBで良く三角関数を利用するのですが、このとき 
Math.Sin(Ang)といった使い方をしていますが、この書き方はクラスのインスタンスを作成しない点で同じ方法かな?と思います。 
そのあたりのことを教えてください。