から好し さんの直接の疑問は他の人が答えてくれるでしょうから、
私の方は、「よい設計」という観点から話したいと思います。
以下のようになる原因というのは、
> 1つの.csファイルに長々とコードを書きすぎてしまったので
私の経験では、何でもかんでもクラスを作ってしまったことに起因することが多いです。
では、なぜ、何でもかんでもクラスができてしまうのか？
ありがちなのが、画面クラスに何でもかんでも書いてしまうことです。
例えば、Windowsの電卓のようなソフトウェア。
起動時に表示されるメイン画面が１枚あるだけです。
このようなソフトウェアにおいて、「画面クラスに何でもかんでも書く」をすればどう
なるでしょう？
そうですね、ファイルはたった１つにしかなりません。
そこで。。。
(Windows10の)電卓をよく見ると、標準/関数電卓/...など様々なモードがあります。
これらを、たった一つのクラスで扱うのはどうか？という話があります。
標準/関数電卓などは、機能に差がある(πやlogボタンなど)だけで、基本、計算をする
という意味(+-*/=など)においては差がありません。
なので、計算の標準機能をベースクラスにして、
派生クラスで標準電卓/関数電卓/...などを作れば、
class CalculatorBase;
class NormalCalculator : CalculatorBase;
class ScientificCalculator : CalculatorBase;
:
これだけでクラス(= ファイル)は自然にたくさんに分かれます。
機能ごとのクラス(= ファイル)に分かれたことによって、ソースコードも読みやすく、
設計変更もしやすくなります。
クラス分割は、上記のような機能分割だけではなく、データ分割等によっても好ましく
行うことができます。
例えば、社員管理ソフトウェアのようなものを考えます。
社員管理ソフトウェアのデータをDataBaseで管理しようと思えば、以下のような
テーブルが含まれていても自然でしょう(^^)
・社員情報 (社員番号/氏名/生年月日/性別/住所/...)
・組織情報 (部課番号/部課名/職務/親部課番号/...)
・所属情報 (社員番号/部課番号/業務内容/...)
：
データベースにしたときに、テーブルが分かれそうなものは、C#のクラス化の際もクラス
分けするのが基本的な考え方です(そうとばかりも限りませんが、そういうことが多いと
いう意味)。
長くなりましたが。。。
ただ、「長すぎるからファイル分割」では、逆にソースコードは読みづらくなる可能性
が高いです。
設計レベルでのクラス分割の結果として、ファイル分割が当たり前に自然に起きる。
これが「よい設計」だと思うのです。
|
