C# 設計メモ – テックメモ

順不同。思いつたら更新。

・クラスの単位

GUIのフォーム単位のクラスが基本(GUIがなければユースケース管理)で、その中で必要に応じてクラスに抜き出す。

１．変更の発生しそうな部分をクラスに抜き出す。
拡張ポイント(DI)

２．共通で使う部分をクラスに抜き出す。
アダプター(合成＋委譲)で共通化
ストラテジー

３．他クラスから参照される部分をクラスに抜き出す。

４．テストしたい部分をクラスに抜き出す。

５．インスタンス生成をクラスに抜き出す。
生成処理を1箇所にまとめることで変更に対応しやすく。
DIが連続して上位レイヤーに引数が溢れてきたら。
(作ると使うを分ける)

６．プリミティブな値に型定義する場合。
値オブジェクト

・クラス、インターフェース、メソッド

参照と変更を分ける(CQS)。意味のある名前にする。スコープが大きいのに一文字変数名や、ハードコーディングしている数値など避ける。とりあえずメソッドは小さく。

・レイヤー

適切にクラス分けしていけば最終的に自然とレイヤーに当てはまる形になっているのでそれほど意識しない。

・依存関係のコントロール

クラス間の依存をインターフェースへの依存にすること。派生クラスの追加で対応する。拡張ポイントと呼ぶ場合もある。

    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            // 下位レイヤーに依存すると下位レイヤーの変更に影響を受ける

            new App("");
            // AppでSayHelloのインスタンス生成をしている 

            new App();
            // SayHelloのインスタンスをBuilderで生成し、App内で利用している
            // (生成と利用の分離)

            new App(new Builder());
            // Builderの生成をAppの生成と同じレイヤー化
            // AppはBuilderに依存(利用)していたが、
            // App、BuilderともにIFactoryに依存することになる
            // (DI)
        }
    }
    
    class App
    {
        public App(string dummy)
        {
            new SayHello().Do();
        }

        public App()
        {
            new Builder().CreateObj().Do();
        }

        public App(IFactory f)
        {
            f.CreateObj().Do();
        }

    }

    class Builder : IFactory
    {
        public SayHello CreateObj()
        {
            return new SayHello();
        }
    }

    interface IFactory
    {
        SayHello CreateObj();
    }

    class SayHello
    {
        public void Do()
        {
            MessageBox.Show("hello");
        }

    }

public partial class Form1 : Form

{

public Form1()

{

InitializeComponent();

// 下位レイヤーに依存すると下位レイヤーの変更に影響を受ける

new App("");

// AppでSayHelloのインスタンス生成をしている

new App();

// SayHelloのインスタンスをBuilderで生成し、App内で利用している

// (生成と利用の分離)

new App(new Builder());

// Builderの生成をAppの生成と同じレイヤー化

// AppはBuilderに依存(利用)していたが、

// App、BuilderともにIFactoryに依存することになる

// (DI)

}

class App

{

public App(string dummy)

{

new SayHello().Do();

}

public App()

{

new Builder().CreateObj().Do();

}

public App(IFactory f)

{

f.CreateObj().Do();

}

class Builder : IFactory

{

public SayHello CreateObj()

{

return new SayHello();

}

interface IFactory

{

SayHello CreateObj();

}

class SayHello

{

public void Do()

{

MessageBox.Show("hello");

}

・DB系

DBの依存関係。FKがある方が依存している。依存している方が子。PKは重複できないけど、FKは重複できるので、FKある方が多。

複合主キーとなっている関係従属を取り除く正規化は当たり前に発生するので、正しいモデリングをすると必然的に複合主キーが現れる。サロゲートキーを入れる場合、制約はアプリ側で対応する。例えば仕入価格を、仕入先・商品・開始年月で識別するような場合。

参照整合性。実務では完全な制約が必要ではなく、緩い制約の方が都合がいいときもある。ただし、構造が壊れやすくはなるので注意。