Programming,  その他

オブジェクト指向について思う事③

こちらは、前回の続きです。

私は、クラス構成を考える時には、会社を作るつもりで考えます。まず、会社には当然社長がいますよね。社長は開発用のツールを使えば最初に自動で生成されるApplicationクラスです。main関数内ではこんな感じじゃないでしょうか。

static void Main(string[] args)
{
    XXApplicaion app = new XXApplicaion();
    app.Initialize();
    app.Run();
}

次に、どのようなクラスを作るといった細かい単位ではなく、この会社には何の部があるんだろうと組織図を考えます。例えばデータベースアクセス部とかです。これは、既存のライブラリー、フレームワークを使う事がほとんどじゃないでしょうか。ここで考える部の構成は、1つのクラスのみのだったりもします。パラメータ情報保持クラス課とかです。パラメータが各種あり複数のクラスを有する場合は統括する部長が必要ですが。あとは、業務A部とか業務B部とかです。部が決まれば、部長を配置します。部長クラスの作成です。大体私は「XXManager」とか「XXMgr」クラスという名前を付けます。これらの部長は当然社長が管理し社長が生成します。次に各部の中の構造に入ります。階層構造はその業務によりけりですが、ヒラ社員のクラスを考えます。このヒラ社員こそ「オブジェクト=名詞」です。クラス名が名詞であることに大きな意味がある。オブジェクト指向って天才的なネーミングセンスじゃないですか。このヒラ社員は同じ型の社員が、数千、時には数万という単位で部長(もしくは課長かもしれませんが)にリストなどで管理されてたりします。そして、このヒラ社員は他の部に出向したりする時もありますが、どの部長が生成し管理するかが非常に重要です。UMLで言うところの「has-a」関係ですね。これはクラスの名称の意味を考えれば自ずと答えは出てくるはずです。このヒラ社員のポイントは現実世界とは逆行して指示待ち人間になることです。出世の望みはありませんから(笑)上司から指示された時(関数が呼ばれた時)のみ動き、言われたことだけしてればいいのです。次に部長ですが、こちらは現実世界と同じです。自分で仕事は出来るだけしないでください。指示に徹するのです。「Aさんこれをこのような条件になるまでやって、次はBさんこれね。」といった風に、おそらくfor文if文等を駆使して部下に仕事を指示(部下の関数を呼ぶ)します。どのように采配を振るうかは部長の腕の見せ所ですが、クラス構成をどのようにして、どのクラスにどの関数を置くかによると思います。

あと、大体どのアプリにもあるのですが、庶務課というのがあります。システムには最初の文字を大文字にするとか、決まったコードを付加するとか、大抵システムに共通した雑務的な処理があります。これを行うのが庶務課で、ユーティリティなクラスまたはクラス群ということになります。この庶務課にお願いする関数のポイントは、static関数になり得るかという事です。もし雑務的な処理だったとしてもメンバーを持たなければ出来ない処理であればここに入れるべきではないと思います。メンバーを持たないといけない時点で雑務ではないです。

そして、会社には欠かせない人がいます。営業マンの存在です。これは、例えば通信制御のサーバでは、受信データのコールバック関数を保持するクラスということになります。営業マンはデータを受信したら、社長または部長のオブジェクトへの参照変数を保持していて、「こんなデータが来ましたのでお願いします」と渡してあげます。また、送信するデータを各部長からもらえば、「かしこまりました」と言って、然るべき場所にデータを送信します。営業マンは営業活動に徹して、まかり間違っても業務はしないように。ここで部長オブジェクトを作成するなんてもってのほかです(笑)

だいたいこんな感じでできます^^

Follow me!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

PAGE TOP