C# 拡張メソッドについてメモ

拡張メソッド (C# プログラミング ガイド)

拡張メソッドは別クラスで宣言した静的なメソッドをインスタンスメソッドのように記述出来るもの。

まずは拡張メソッドでメソッドで追加するクラス

namespace Nmdm
{
    public sealed class Hoge
    {
    }
}

そして拡張メソッド

namespace Nmdm
{
    public static class HogeExtension
    {
        public static void ExtensionMethod(this Hoge obj)
        {
        }
    }
}

このように静的なメソッドの第一引数にthisという記述をすると、第一引数の型に対する拡張メソッドの宣言となる。

使う場合は以下のようにする。

namespace Nmdm
{
    public sealed class HogeClient
    {
        public void DoSomething()
        {
            var hoge = new Hoge();
            hoge.ExtensionMethod();
        }
    }
}

あくまでインスタンスメソッドのように見せかけて記述出来るだけであって、
実態はstaticメソッドです。

そのため、以下のように記述することも出来ます。

namespace Nmdm
{
    public sealed class HogeClient
    {
        public void DoSomething()
        {
            var hoge = new Hoge();
            // hoge.ExtensionMethod();
            HogeExtension.ExtensionMethod(hoge);
        }
    }
}

インスタンスメソッドに同じスコープ、同じシグネチャのメソッドがある場合、インスタンスメソッドが優先される。

このように拡張メソッドを宣言して。

namespace Nmdm
{
    public static class HogeExtension
    {
        public static void SameMethod(this Hoge obj)
        {
        }
    }
}

同じシグネチャのインスタンスメソッドがある場合

namespace Nmdm
{
    public sealed class Hoge
    {
        public void SameMethod()
        {
        }
    }
}

以下の記述で実際に動くのはインスタンスメソッドの方

namespace Nmdm
{
    public sealed class HogeClient
    {
        public void DoSomething()
        {
            var hoge = new Hoge();
            hoge.SameMethod();
        }
    }
}

このような事情から基本ライブラリのクラスに対して拡張メソッドを実装するとバージョン変更により意図しない動作をしてしまう可能性がある。
もし拡張メソッドを使うのであれば完全自作クラスないしは自作インターフェースのみを対象にした方が良さそうですね。

拡張メソッド自体はインスタンスの状態を持つことは出来ないけど、
少し工夫すればC#でもミックスイン（のような）実装が出来そう。

…ていうのをWPFの添付プロパティやビヘイビアを勉強していて思いました。

WPF ObservableCollectionのチューニング

WPFがもっさりしているのでいろいろ検索している中でなるほどーとなったもの、大事そうなのでメモします。

Twelve Ways to Improve WPF Performance | Pelebyte

ObservableCollectionでこんなようなことをしてたとして。

using System.ComponentModel;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace Nmdm
{
    public sealed class AboutObservableCollectionTuning : INotifyPropertyChanged
    {

        public event PropertyChangedEventHandler PropertyChanged;

        public ObservableCollection<Person> Persons { get; }

        /// <summary>
        /// 公開しているObservableCollectionを更新するなにかの処理
        /// </summary>
        public void UpdatePersons()
        {
            // コレクションを初期化する。
            this.Persons.Clear();
            // メソッドの戻り値をコレクションに追加する。
            foreach(var obj in this.GetPersons())
            {
                // Addメソッドの度に変更通知が発生する。
                this.Persons.Add(obj);
            }
        }

        /// <summary>
        /// 更新結果を取得するダミーの処理
        /// </summary>
        private IEnumerable<Person> GetPersons()
        {
            return new Person[] { };
        }
    }
}

以下のようにする。（元の記事と全然違うけど・・・）

using System.ComponentModel;
using System.Collections.Generic;
using System.Collections.ObjectModel;

namespace Nmdm
{
    public sealed class AboutObservableCollectionTuning : INotifyPropertyChanged
    {

        public event PropertyChangedEventHandler PropertyChanged;

        public ObservableCollection<Person> Persons { get; private set; }

        /// <summary>
        /// 公開しているObservableCollectionを更新するなにかの処理
        /// </summary>
        public void UpdatePersons()
        {
            // コレクションの空のインスタンスを生成
            var updatedPersons = new ObservableCollection<Person>();
            // メソッドの戻り値をコレクションに追加する。
            foreach(var obj in this.GetPersons())
            {
                updatedPersons.Add(obj);
            }
            // プロパティに張り替える。
            this.Persons = updatedPersons;
            // 変更通知出す（必要あり？）
            if (this.PropertyChanged != null) 
                        this.PropertyChanged(this, new PropertyChangedEventArgs(nameof(this.Persons)));
        }
        /// <summary>
        /// 更新結果を取得するダミーの処理
        /// </summary>
        private IEnumerable<Person> GetPersons()
        {
            return new Person[] { };
        }
    }
}

書き方の良しあしは別として、
大事なのはAddメソッドの度に変更通知を飛ばさないようにしよう。
ということですね。なるほどなるほど。

■

こちらの記事を参考に、ソースコードを貼ってみる。

ブログにソースコードを見やすく掲載する方法【C#】

ブログにソースコードを見やすく掲載する方法【C#】 - 備忘録

public class Hoge()
{

}

なるほどこれは便利、Gistより楽ですね。

MVVMでDDD

「MVVMのModel＝DDDのドメインモデルですね。」みたいな記述をどこかで見かけて。

はたしてそうか？と思った。

実装都合だけで考えるとDDDのUIの中にMVVMが全部入っている風にしちゃって良いと思う。

ViewModelはViewにバインドするメンバを公開するのが仕事、

ModelはDDDのアプリ層に処理を委譲するのが仕事、

それだとMVVMのModel＝アプリ層ともとれる？

セオリーとは違ってて多少冗長でも各々の責任が明確になっていればそれで良いと思う。

（そもそもＤＤＤもＭＶＶＭも全然理解出来ていない言い訳みたいなものですが。）

ＤＤＤ本でも書いてあったと思うけど、

「ＤＤＤとはなんたるか」に捉われるより自分達の環境にマッチするパターンを構築して行きたいと考える今日この頃です。

WPF DataGridのSelectedItemプロパティにバインド

ちゃんと検証していないけど結構はまったので考察します。

DataGridで選択中の行をViewModelで把握するために、

SelectedItemプロパティにバインド。

が、DataGridが一行しかないとき、画面でクリックしてもなにしても、

ViewModel側のSetterに飛んでこない。

一回でもモデル側でコレクションをリフレッシュし、

DataGridにバインドしているコレクションを更新するとSelectedItemプロパティにバインドしているViewModelのプロパティが更新される。

ViewのコードビハインドでDataGridのプロパティを洗ってみると、

View側は先頭行が選択状態になっていたが、ViewModelに通知されておらず、

以降画面でクリックしてもなにしても、Viewはプロパティの更新なしと判断してViewModel側に更新通知をしていなかった。

つまり、

View⇒DataGridの先頭行を選択

ViewModel⇒SelectedItemプロパティにバインドしているけど、選択されていない状態

という具合になっていた模様。

この時、BindingのModeはTwoWayになっていたが、

これをOneWayに変更すると画面を表示した直後からViewModel側にもSelectedItemプロパティの値が設定されていた。

＝＝以下予想＝＝

・バインドの初期化はDataContextプロパティにViewModelのインスタンスを渡した瞬間に実行されるわけではない？

・「対象Viewの描画されている状態」かつ「DataContextにViewModelが渡された状態」になった時にバインドの初期化処理が実行される？

⇒調査中DataContextにプロパティを設定する処理とViewを描画する処理を入れ替えてみたら、ViewModelのGetterはその時の後のステップに反応していた。

・初期化処理はTwoWayの場合、ViewModel⇒View、OneWayの場合View⇒ViewModelの方向でしか実行されない？？？

・DataGrid自体がBindingの有無に関わらず、自動的に先頭行がSelectedItemに格納されると仮定すると、TwoWayで上手く行かず、OneWayで上手くいったのも納得出来る。WindowsForm時代のDataGridViewでも似たような話があったような・・・

OracleSqlDeveloper

OracleDatabaseをインストールするとjdkフォルダの中に最初からsqldeveloperが入ってる。

今まで知りませんでした。

WPFスタイル⇒コントロールテンプレート⇒ユーザーコントロール ？？？

リソースディクショナリにTextBoxをターゲットにしたスタイルを記述、

コントロールテンプレートでユーザーコントロールを追加し、

ユーザーコントロールのプロパティにテンプレートバインディング。

これを画面からバインディングしようとしても上手くいかず。

そもそもこういう使い方って出来るものなのか…

上手くいけばスタイルだけ公開して利用者からユーザーコントロールを隠蔽出来て良さそうなのですが・・・