VC#で汎用的な関数はどのファイルに書くのですか？

質問

このたびVisual Studio C#でWindowsフォームアプリケーションを作り始めたのですが
コードはForm1.csに書くのが普通なのですか？

VBAを使っていた時は、Formにはコントロールのイベントの関数を書いて、その関数内での
処理はModulの中に書いていました。
Modulをnamespaceのような扱いで、ファイル関係の関数を集めたModulをModul_file、
文字列処理を集めたModulをModul_strなどと機能毎にModulを作っていました。
クラスは使っていませんでした。

このような使い方が合っているのかわかりませんが、VC#ではクラスにするほどでないような汎用的な自作関数を集めたものはどのファイルにすれば良いのでしょうか？
Form1.csに書くのもなんか違うような気もします。

よろしくお願い致します。

回答No.1

anmochi · ベストアンサー

VBAで言うところの標準モジュール的なファイルは好きなように作って良いでがす。

例えば、StringUtils.csというファイルを作ってその中に
namespace Utils
public class StringUtils {
private StringUtils() {
}

public static bool isEmpty(string t) {
return t == null || t.length == 0;
}

}
などと書けばそれは全てのプログラムからUtils.StringUtils.isEmpty("test")などと呼び出す事ができる。上のコードはソラで書いたので細かい文法は間違っているかも知れないのでその時は適時直してください。この時、メソッド（関数）はpublic staticで定義しないとVBAの標準モジュール的に使う事ができない。また、private StringUtils()はプライベートコンストラクターと言って、このStringUtilsクラスをインスタンス化させない目的で使っている。

ただ、VBAのようななんちゃってオブジェクト指向な言語では標準モジュールはありがたい存在だったが、C#では可能な限り正統派オブジェクト指向なクラス分けを考えていくほうが良いだろう。

お礼

ありがとうございます。
まだ正統なオブジェクト指向がどういうものか理解しきれていませんが非常に参考になりました。

回答No.3

松延 英樹（@maznobu）

良し悪しの論議は置いといて、

どの言語でも、オープンソースやプロプライエタリ製品などソース管理では、
一般的にカテゴリ別にクラスを作り、staticメンバで実装するのが定石ではないかと思います。

どういうカテゴリにするかは技術者の裁量ですが、
文字列操作なら StringUtil、描画関係の操作ならGraphicsUtilなど。

クラス分けやネームスペースを理解し考えるのは、プログラミングの大事な工程の一つで、
オブジェクト指向を理解する上でも最も大事な部分です。
この作業は人によってはつまらない作業かもしれませんが、
理解できるようになってくると、プログラマの楽しみであると同時に、
エンジニアとしてのスキルとしても大変役に立つのでぜひお勧めします。

ジェネリックなどはSystem.Collections.Genericに入れる方も居られますが、
システムのクラスなのか独自クラスなのかわからなくなり煩雑になりますので、
自分の作るアプリのカテゴリに分けて定義したほうがよいと思います。
（jp.myapp.Generics.MyList<E>など。）

また、クラス化するのはネームスペースの延長、最終的なカテゴリ分けをするためで、規模を隠蔽するためではありません。
よってどんなに小さいメソッドであっても汎用性があるものならばクラス化して集約したほうがよいと思います。
メンバ関数の数が増えてきたら自分のライブラリとして、外だしのライブラリプロジェクトをつくり、
ライブラリに署名を付けておくと、今後作るであろういろいろなアプリから利用できるようになると思います。

クラス名の命名としては、たとえばアプリケーションのネームスペースがjp.ahoo で、文字列を操作するクラスならば、
jp.ahoo.utils というネームスペースやパッケージの下に、クラス名 StringUtil などがあるでしょう。

ただ、外部クラス化することで処理が面倒になる場合もあります。パフォーマンスが落ちるのならば、
無理に外出しにする必要はないかもしれません。
スニペットなどもうまく利用してご自身が作られるコードをテンプレート化しておくのもよいと思います。

お礼

ありがとうございます。
とても丁寧で詳しく教えてくださって感謝します。

回答No.2

foomufoomu

何でもかんでもクラスにする風潮には、懐疑的に考えています。
本来、クラスは、構造化プログラミングと同じく、プログラミングの時にいくつかのルールを課すことで、バグを減らし、見通しをよくしてデバッグをやりやすくするためのものなので、その目的に合わないものは、クラス化するべきでないと思っています。
たとえば、数学のSin関数を　Math.Sin とクラスにするなどは、不必要に式の文字数を増やして見にくくし、デバッグを不便にする以外、何かの役に立つのか？　とか。

では、どのようなものをクラスにするべきかというと、プロパティ、メソッド、という言葉がしっくりくる情報の集合体をクラスにするべきではないかと考えています。
たとえば、図形処理をするプログラムなら、三角形などのクラスをつくって、
TriAngle1.Axis=・・・　等で、形を定義しておけば、あとは、
Menseki=TriAngle1.Area；　として面積をもとめたり、
Kyori=TriAngle1.Distance(Triangle2)；　として別の三角形までの距離をもとめたり、
Triangl1.Display; で、画面に表示したり、
といった処理をするのは、自然なことでしょう。

オブジェクト指向という言葉は、それまでのプログラミングのスタイルが、処理・命令を基準に塊を作っていたのに対し、(質問者さんの、ファイル処理、文字処理でモジュールを作るという考え方です)
目的とする情報(これがObject。前の三角形の例)を基準に考えて塊をつくるという考え方です。

ファイル処理でも、それを処理で区切るのでなく「入力データの集合体」などと考えれば、自然なクラス化も可能ではないかと思います。
あくまで、無理のない範囲で、すこしずつオブジェクト指向に慣れていけばよいと思います。
オブジェクト指向、クラス、というものは、機械的に書き方を変えるのでなく、まず、考え方を変えることであると気づくことが大事でしょう。

お礼

ありがとうございます。
クラスについて非常に参考になりました。
無理にクラス化するのもいけないのですね。

＞では、どのようなものをクラスにするべきかというと、プロパティ、メソッド、という言葉がしっくりくる情報の集合体をクラスにするべきではないかと考えています。

これを頭に入れておくようにします。