NetFramework では、null代入可能な値型をNullable<>型によって表します。T?と略記することができます

一方、参照型ではもともとnull代入可能なので、逆にnullが代入できないことを表す型がなく、実行時にNullReferenceExceptionが発生して初めてミスに気付くことが度々あります。

これを解決するためC# 8.0ではnull許容参照型が導入されました。

記法はnull許容値型と同じく、型名の後に?を付けます。

但し、新たに型が追加されたわけではなく、同じ型についてnullが許容されるかどうかを判別する仕組みで動作します。NullReferenceExceptionが発生する可能性があると思われる場所には、コンパイル時に警告が出るようになっています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

namespace NullableReferenceTypeTest
{
  class Test { }

  class Container<T>
  {
    public T? Value { get; set; }

    public Container(T? value)
    {
      Value = value;
    }
  }

  class Client
  {
    public T? GetValue<T>(Container<T?> container)
    {
      return container.Value;
    }

    public void GetValueTest()
    {
      var c1 = new Container<Test>(new Test());
      var v1 = GetValue(c1); //警告発生
      var c2 = new Container<Test?>(null);
      var v2 = GetValue(c2); //警告が発生しない
    }
  }
}

C# 9.0 では制約がない型引数に ? をつけれるようになりました。

ジェネリックで制約がない型引数を使ってnull許容かどうかにかかわらず使えるクラスを作成する場合、型引数に ? をつけると問題が発生します。

右のコードはこのような場合に余分な警告が発生することを示すものです。
Container はnull許容かどうかにかかわらず使うことを意図したクラスです。
GetValueTest では c1 にnull許容しない型Testを実引数Tに設定しています。
それに対してc2にはnull許容する型Test?を実引数Tに設定しています。
それぞれGetValueで値を取得しているのですが、null許容しない型c1を引数に指定した場合は警告が出ます。

#nullable enableは、以降でnull許容参照型を有効にすることを示しています。
同様に#nullable disableで無効になり、#nullable restoreで以前の設定に戻ります。

対策としては ! をつけて警告を無視させることも考えられます。

しかし、null許容かどうかにかかわらず使えるクラスの型引数にnull許容参照型を指定することは、上記のあいまいさがあるので、当面これに該当する部分はnull許容参照型を無効のままにしようと考えています。

ジェネリックでない型や、ジェネリックの場合でもnullを許容するかどうか用途が決まっている場合には、null許容参照型を使っていこうと思います。

ASP.NET MVC5を採用したシステムを手がけています。言語は C# を使用しています。

前回手がけた有名どころのフレームワークSymfonyとの比較にも触れます。

コンパイル

PHPでは実行時にコンパイルが実行されるので大きなライブラリーを使用するのにためらいがあります。
ASP.NET(C#)ではコンパイル済みになっているのでパフォーマンスがよいと思われます。

メモリ

Symfony でバッチ処理した場合、メモリ食いが激しく、数万件の処理でも問題があったので、Doctrine管理外のプレーンオブジェクトを使う、クエリで最低限必要なカラムのみ読み込むなどの工夫が必要でした。経験上C#で数万件の処理はオンメモリで問題なく扱えます。

テンプレートエンジン

Razerが標準で使えます。インテリセンスも効いて Typo を防げます。
但し、デザイナーとの分業を考えたとき、Razerは開発者向けなので継続的にデザイナーに編集を依頼するのは難しいと思います。
この点はSymfonyが採用しているtwigでも事情はあまり変わりません。

フレームワークの柔軟性

テンプレートエンジンはRazer、O/RマッピングはEntity Frameworkが標準で使えるようになっていますが、これを差し替えることができます。
テンプレートエンジンはデザイナーと協業できるテンプレートに差し替え、O/Rマッピングは普段使用しているフレームワークに差し替えました。
差し替え時、ASP.NETが持っているバリデーションの機能を使えるようにするため工夫が必要でした。差し替えのためにはフレームワーク内部の動作を理解する必要があります。

ASP.NET MVC5採用決定時に、ASP.NET Coreについても検討したのですが、利用予定のActiveReportsが対応していなかったので不採用となりました。

phpでSymfonyを採用したシステムを開発しました。開発を通じて感じた利点・欠点を紹介します。

次の点が優れていると思いました。

• DoctrineにO/Rマッパーの機能が一通り揃っている。

• 標準的なフォーム部品に相当するクラスが用意され、しかもカスタマイズしやすい。

• データベース・ドメイン間、ドメイン・ビュー間の変換をカスタマイズしやすい。

• フォームが階層構造に対応しているため、マスター・ディテールフォーム・部品表などのツリー構造を持つデータに容易に対応できる。

  次のような点が不便と思いました。

• 学習コストが大きい。

• DQLが使いにくい。

• エンティティで関連を操作する際、参照が必要になるので回りくどい処理が必要になる場合がある。

• エンティティがDIで生成されるので大量の行を操作すると処理が重い。

• データベースからエンティティを生成する機能があるが、必ずしも適切なエンティティを生成しない。

• 既定ではサブエンティティ（明細行）を保持する配列のキーとしてカラムの値が使われ、それがINPUT要素の名前の一部に使われ、文字によってはエラーになるので、これを回避しなければならない。

他のフレームワークと比較しました。Symfony のほか Laravel, ASP.NET5 の経験はありますが。 開発経験がない他のフレームワークはドキュメント等や各種Webサイトの情報を元に判断しました。

対話型システムで Windows Forms をはじめイベント駆動で処理を記述するプラットフォームでは、ドメインロジックからキーの処理まで雑多な処理が集中しがちになるといった反省から、レイヤーアーキテクチャを採用しています。書籍を読んだりインターネットの情報を吸収してそれなりの効果を上げていると考えています。

雑多な処理を分離するもう一つの方法があります。それはイベントハンドラをフォームから分離してしまうものです。下記コードはWindows Forms に対応するもので、エンターキーでフォーカス移動したいとの要望にこたえるものです(但し当方のライブラリの呼び出しがありますのでそのまま使えるものではありません)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

/// <summary>
/// Enter キーが押されたら Tab キーに変換します。
/// </summary>
public class EnterToTabHandler
{
  Form Form;
        
  void FormKeyDown(object sender, KeyEventArgs e)
  {
    if (e.Handled) return;
    if (e.KeyCode == Keys.Enter && (e.Modifiers & (Keys.Alt | Keys.Control)) == 0) {
      var control = ViewUtility.GetCurrentControl(Form);
      if (control is TextBoxBase && !(control as TextBoxBase).Multiline ||
        control is ComboBoxBase && !(control as ComboBoxBase).DroppedDown ||
        control is CheckBox || control is RadioButton) {
        SendKeys.Send("{TAB}");
        e.SuppressKeyPress = true;
      }
    }
  }
  
  /// <summary>
  /// <see cref="EnterToTabHandler"/> 型のインスタンスを作成します。
  /// </summary>
  /// <param name="form">処理対象となるフォーム</param>
  public EnterToTabHandler(Form form)
  {
    Form = form;
    form.KeyDown += FormKeyDown;
  }
}

利用するフォーム側ではEnterToTabHandlerのコンストラクタ呼び出しを１行記述だけです。

他にもボタンを押したらモデルのコマンドを実行するもの、ファンクションキーを押したら特定のボタンをクリックしたことにするものなど、多くの処理をフォームから追い出すことができます。

この方法は次のようなメリットがあります。

• 継承を気にしないで使うことができるので機能間の分離が良い
• 継承とは異なり、多重度に縛られない（モデルのコマンドを実行する例ではボタンとコマンドの組み合わせをいくつ持っても良い）

そしてこの方法はAccessVBAでも使えて当方では長く実績があったものです。

現在は Windows Forms でレイヤーアーキテクチャと組み合わせて使っています。従来はビューとモデルがパラレル継承階層となっていて硬直していたのですが、ビューの機能継承に縛られなくなったので、ビューはもっぱらデザインの継承階層、モデルは編集、一覧など機能での継承階層と全く別のベクトルで継承するようにしました。

データベースアプリケーションのテクニックの1つにアイデンティティ・マッピングがあります。これはデータベース上の行とメモリー上のオブジェクトを１対１に対応させようというものです。すべての行をメモリーに読み込むという意味ではなく、１つの行に対応するオブジェクトを複数作成しない点に主眼が置かれています。一意マッピング・恒等写像などと訳すことができますが、ここではアイデンティティ・マッピングと呼んでおきます。

１つの行に対応するオブジェクトがメモリー上に複数ある状況というのは、複数画面で同じ行を参照している場合に起こりやすいです。例えば一覧画面でロードしたいずれかの行が別画面で表示されていたりロジック実行で必要となったりといった状況です。

１つの行に対応するオブジェクトがメモリー上に複数あると、行を更新したときに同じ行に対応する別のオブジェクトも更新する必要があります。これを怠ると更新前のオブジェクトが表示されたり、更新前のオブジェクトを使ってロジックが実行されるといった不具合が発生します。アイデンティティ・マッピングではオブジェクト更新時に同じ行を表す別のオブジェクトがありませんのでこのような配慮が不要となります。

アイデンティティ・マッピングを実現するためにテーブルの主キーをキーに持ち、行に対応するオブジェクトを値に持つディクショナリーを用意することが考えられます。データベースからテーブルを読み取ったときは、このディクショナリと突き合わせ処理して、同一キーの要素があればオブジェクトのプロパティをデータベースから読み取った値に更新します。同一キーの要素がなければディクショナリーに追加します。リポジトリーにこのような仕組みを持たせておけば、すべての読み取り処理でアイデンティティ・マッピングを施すことができます。

この仕組みで問題となるのが行に対応するオブジェクトを保持するために設けたディクショナリーは要素を除外することができず、プログラム起動後に１度でも読み取った行が居座り続けるためメモリーを圧迫することです。NetFrameworkのガーベジコレクターはどこからも参照されなくなったオブジェクトを破棄対象とみなしますが、この場合ディクショナリーが参照を持っているので破棄対象になりません。

そこでこのディクショナリーの要素を弱参照するのです。 どこかの画面から参照されていれば要素は破棄されませんがどの画面からも参照されなくなりディクショナリーが弱参照するのみとなればガーベージコレクターによる破棄対象となります。

下記は要素を弱参照で持つディクショナリの例です(C# 6.0文法を使用しています)。インデクサーは読み取り専用にしています。新しい要素は内部で保持するItemCreatorによって作成します。RemoveDeadItems()によって破棄済みの要素を除外します。このようなディクショナリーを使って読み取ったデータを保持します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

/// <summary>
/// 弱い参照によって、キーに対応する値を保持します。
/// </summary>
/// <typeparam name="TKey">キーの型</typeparam>
/// <typeparam name="TValue">値の型</typeparam>
/// <remarks>
/// このオブジェクト以外から参照されなくなった値はガーベジコレクションの対象となります。
/// ガーベジコレクションによって破棄された値を参照したときは、再作成します。
/// 全ての値を保持するとヒープメモリが不足する恐れがある場合に使用します。
/// </remarks>
public class WeakReferenceDictionary<TKey, TValue> : IEnumerable<KeyValuePair<TKey, TValue>
  where TValue : class
{
  IDictionary<TKey, WeakReference<TValue> UnderlyingDictionary = new Dictionary<TKey, WeakReference<TValue>();

  /// <summary>
  /// キーに対応する値を作成する関数を取得します。
  /// </summary>
  public Func<TKey, TValue> ItemCreator { get; private set; }

  /// <summary>
  /// 破棄されているキーのシーケンスを取得します。
  /// </summary>
  IEnumerable<TKey> GetDeadKeys()
  {
    foreach (var kv in UnderlyingDictionary) {
      TValue target;
      if (!kv.Value.TryGetTarget(out target)) yield return kv.Key;
    }
  }

  /// <summary>
  /// 破棄された値を持つ要素を除外します。
  /// </summary>
  public void RemoveDeadItems()
  {
    lock (this) {
      foreach (var key in GetDeadKeys().ToArray()) {
        UnderlyingDictionary.Remove(key);
      }
    }
  }

  /// <summary>
  /// キーに対応する値を取得します。
  /// </summary>
  /// <param name="key">キー</param>
  /// <returns>キーに対応する値</returns>
  /// <remarks>
  /// キーに対応する値がないかまたは既に破棄されている場合は <see cref="ItemCreator"/> によって作成します。
  /// </remarks>
  public TValue this[TKey key]
  {
    get
    {
      lock (this) {
        WeakReference<TValue> value;
        TValue target;
        if (UnderlyingDictionary.TryGetValue(key, out value) && value.TryGetTarget(out target)) return target;
        target = ItemCreator(key);
        UnderlyingDictionary[key] = new WeakReference<TValue>(target);
        return target;
      }
    }
  }

  /// <summary>
  /// 格納されている要素の数を取得します。
  /// </summary>
  public int Count => UnderlyingDictionary.Count;

  /// <summary>
  /// 格納されているキーのシーケンスを取得します。
  /// </summary>
  /// <remarks>
  /// キーに対応する値は破棄されている場合があります。
  /// </remarks>
  public IEnumerable<TKey> Keys => UnderlyingDictionary.Keys;

  /// <summary>
  /// 格納されている値のシーケンスを取得します。
  /// </summary>
  public IEnumerable<TValue> Values
  {
    get
    {
      foreach (var kv in UnderlyingDictionary) {
        TValue target;
        if (kv.Value.TryGetTarget(out target)) yield return target;
      }
    }
  }

  /// <summary>
  /// コレクションを反復処理する列挙子を返します。
  /// </summary>
  /// <returns>コレクションを反復処理するために使用できる <see cref="IEnumerator{T}"/></returns>
  public IEnumerator<KeyValuePair<TKey, TValue> GetEnumerator()
  {
    foreach (var kv in UnderlyingDictionary) {
      TValue target;
      if (kv.Value.TryGetTarget(out target)) yield return new KeyValuePair<TKey, TValue>(kv.Key, target);
    }
  }

  System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() => GetEnumerator();

  /// <summary>
  /// <see cref="WeakReferenceDictionary{TKey, TValue}"/> 型のインスタンスを作成します。
  /// </summary>
  /// <param name="itemCreator"> キーに対応する値を作成する関数</param>
  public WeakReferenceDictionary(Func<TKey, TValue> itemCreator)
  {
    ItemCreator = itemCreator;
  }
}

PHPを使った開発では、しばらくNetBeansを使っていました。

PHPについては正確に補完してくれているのですが、JavaScriptの補完はあまり当てになりません。

情報を探しているとPhpStormというIDEが優れているとの書き込みをよく見かけるので使ってみました。
その結果、JavaScriptについても正確に補完してくれることがわかりました。NetBeansに比べて優れている点としては、

• JavaScriptの補完が正確
• 関数の順序変更が簡単
• Ctrl-Wによる選択領域の拡大が多段階にできる
• ソースコードフォーマットが細かく設定できる
• 箱形選択時のカーソル移動が合理的（各行で異なる長さの単語があってもCtrl-Wで選択してくれるなど）

などです。NetBeansとは違って有償なのですがそれだけの価値はあったと判断しています。

PHPのトレイトを使うと多重継承に相当する処理を記述できることを３種類の帳票の例で紹介しました。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

trait A
{
    public function a(){}
}
trait B
{
    use A;
}
trait C
{
    use A;
}
class D
{
    use B, C;
} //メソッド競合エラー

$d = new D();

トレイトを使い込む内に1つの制限が見えてきました。それはダイヤモンド継承ができないことです(現在ではこの問題は解消されています。恐らくPHP7.3で解消されたものと思われます)。

右のコードで、クラスDは、トレイトBとトレイトCを取り込んでいます。トレイトB、トレイトC共にトレイトAを取り込んでいます。トレイトAはメソッドaを持っています。この場合、PHPではメソッドaが衝突しているという意味のエラーが発生します。トレイトBとトレイトCのそれぞれにメソッドaがあるとみなすようです。

私は共通のトレイトAの実体は1つなのでエラーにならないことを期待しました。includeとinclude_onceに例えれば、includeではなくinclude_onceに相当する動作を期待したのですが実際にはincludeに相当する動作をします。

この回避方法としてはトレイトB、トレイトCでトレイトAを取り込まないで、クラスDでトレイトA、B、Cを取り込むことが考えられます。

但しトレイトB、トレイトCがトレイトAを取り込むことがコード上で明示されないというデメリットがあります。これについてはコメントで注釈しています。

トレイトB、トレイトCをコーディングするとき、トレイトAに関するメンバーをIDEが補完してくれない可能性があります。PHPStormではトレイトをuseしているクラス、この場合はクラスDを通じてAのメンバーを候補に表示してくれます。Eclipseは調査していません。

C#, Javaなど多重継承ができない言語では、複数のクラスをまとめて新たなクラスを作るのに多くの委譲コードを書く必要があります。PHPも多重継承はできません。しかし、version 5.4 からトレイトが導入されましたのでこれを使うと委譲コードを減らすことができます。

エンティティクラスへの応用

３種類の帳票に対応するエンティティを定義するのにトレイトを使いました。

それぞれの帳票は多くの項目印刷項目があり、全ての帳票に印刷する項目もあれば、２帳票でのみ印刷する項目や１帳票でのみ印刷する項目もあります。各帳票の印刷項目は意味的なまとまりがあるものにグループ化することができ、帳票はこれらのグループを組み合わせたものになります。レイアウト上では項目の一つ一つは細い罫線で区切られていて、
グループは太い罫線で区切られています。
帳票とグループの関係は右表のようになっているとします。

もし継承だけでエンティティクラスを作成するのであれば、項目グループAに含まれる印刷項目のみを基本クラスに置き、項目グループB～Eに含まれる印刷項目はそれぞれ帳票１～３のクラスに置くことが考えられます。

この方法は下記の問題があります。

• ２帳票で印刷する項目グループB, Cの実装が重複する
• 項目グループのまとまりを表せない

これを解決するために、各項目グループA～Eをクラスとして、これらのクラスを使って帳票１～３のクラス（以後具象エンティティ）を作成することが考えられます。各帳票クラスの項目グループAを基本クラスとした場合、具象エンティティには項目グループB～Eに定義した印刷項目にアクセスする委譲コードを書く必要があります。委譲コードがあまりにも多いので、各項目グループA～Eをクラスにすることを諦めて最初の方法に戻ってしまいそうです。

1
2
3
4
5
6
7
8
9
10
11

class Report1 {
  use A, B;
}

class Report2 {
  use A, C, D, E;
}

class Report3 {
  use A, B, C;
}

各項目グループA～Eをクラスではなくトレイトとした場合、委譲コードは不要となり無理なく実装できます。

リポジトリへの応用

リポジトリでは以下のようなさまざまな機能が必要となる場合があります。

• データベースにアクセスする機能
• データベース以外のストレージからアクセスする機能
• リポジトリ内にデータをキャッシュする機能
• キーを指定してエンティティを取得する機能
• 抽出条件を指定してロードする機能

各エンティティクラスに対応するリポジトリ（以後具象リポジトリ）ではこれらの機能のすべてが必要になるのではなく、いくつかの機能のみが必要となります。その組み合わせはさまざまです。上記に挙げた機能をトレイトにしておけば、具象リポジトリはトレイトの組み合わせによって実装することができます。

実感したメリット

直接的には委譲コードを減らすことができるメリットがあります。それだけではなく下記のようなメリットが大きいと感じました。

• トレイトはクラスに比べて粒度を細かくしやすいのでそれぞれの機能が明快になる。
• まるでLEGOブロックを組むようにトレイトを組み合わせてクラスを作ることができる。

ドメインオブジェクトがドメイン層の機能を果たす様にするため、その生成時に複雑な処理が必要になります。当方では生成時に次のような処理を行っています。

• 所有する値オブジェクトの生成
• 所有する子エンティティリストの生成
• 参照しているエンティティへの Null Object の生成
• 変更通知機能(INotifyPropertyChanged)の注入
• 編集・取消機能(IEditableObject)の注入
• 変更トラッキング機能の注入
• 継承の解決

これら生成時の処理の多くは開発するアプリケーションのドメインに依存しない処理となります。そこで生成の機能をファクトリにまとめ、ドメインオブジェクトから分離しています。

生成するドメインオブジェクトはその機能によって下記の３種類に分類しています。

これらはUnity依存性注入コンテナを利用した３種類のビヘイビアを用意して、生成時に使い分けています。

生成時の処理の内、継承の解決はドメインに依存します。データベースで継承を表す方法として、シングルテーブル継承・クラステーブル継承・具象テーブル継承があります。このうちシングルテーブル継承を当方はよく使います。例えば販売管理で売上と入金がありこれを別のテーブルで管理しないで１つの伝票というテーブルで管理し、伝票区分コードというカラムによって売上と仕入を識別しています。データベースからエンティティをロードするとき伝票区分コードによって売上オブジェクトを作成するか仕入オブジェクトを作成するかを振り分けます。

レイヤーアーキテクチャーで使用されるテクニックにレイヤースーパータイプというものがあります。各レイヤーは基本となるクラスを設けて、具象画面用のクラスはこれらの基本クラスを継承します。この基本となるクラスをレイヤースーパータイプと呼びます。複数のレイヤーでレイヤースーパータイプを使用するとそれぞれのレイヤーで継承階層ができます。それぞれのレイヤーは一方を継承すれば別のレイヤーも継承が必要になる場合があります。このような状態をパラレル継承階層と呼び、アンチパターンの１つとされています。

このような状況をアンチパターンとみなすかパターンとみなすかメリット・デメリットを天秤に掛ける必要があるでしょう。NetFrameworkではDataTableとTypedDataTable、DataRowとTypedDataRowにパラレル継承階層が見られます。入れ物と中身の関係で中身を継承すると入れ物も継承しなければならないといった場合がありますので私はアンチパターンと言えない場合もあると考えています。

別の継承階層を参照している継承階層では継承のたびにダウンキャストが発生します。この場合はView側でアプリケーション層のクラスを参照するのにダウンキャストが発生します。

パラレル継承階層においてダウンキャストを無くすためにはコーディングの工夫で対応することはできず、言語が対応する必要があります。

例えば下記のような機能があると良いのです。

継承可能な型引数をサポートすること

C#等現在普及している言語は、継承によってジェネリックの型引数を実体化すると型引数が固定されてしまい、さらに継承する場合には型引数をオーバーライドすることができません。ダウンキャストを無くすためにはオープンジェネリックのままで型引数を実体化できる必要があります。

ジェネリックワイルドカードをサポートすること

継承可能な型引数をサポートするとリスコフの代入原則(一般には置換原則と邦訳されている)との整合性をどうするかが問題になります。型安全を保ったまま他の階層の継承されたクラスを操作できるようにするためには、Javaで実装されているジェネリックワイルドカードをサポートする必要があります。

残念ながら現状ではダウンキャストを無くすことはできません。