WPF依存関係プロパティのバインドモード初期値
依存関係プロパティをバインドする際にModeを省略した場合、
個々の依存関係プロパティ毎に選択されるModeの既定値は異なるとのこと。
ちなみにTextBoxはTwoWayです。
Modeを省略してTextBoxにバインドするのに慣れて、
ユーザーコントロールを自作して同じような記述でバインドするとプロパティが連動せずあれ？？？となりました。
自作の依存関係プロパティでバインドする時のModeの既定値を変更するには、 DependencyPropertyのRegisterメソッドでプロパティを登録する時に、
メタデータにFrameworkPropertyMetadataクラスを指定する。
このクラスのコンストラクタにModeの初期値を指定するパラメータがありました。
情報源は失念しましたが、この辺りのことを調べているときに、
Modeを初期化するとフレームワークのバージョンアップ？でデフォルトの挙動が変わってしまった。という記事も見かけたような気がしました。
Modeは省略しないで書くようにした方が良いかもしれませんね。
WPF BlendのBehaiviorは
WPF BlendのBehaiviorクラスで作ったビヘイビアはそのままではStyleで使うことが出来ない。
少し仕組みを作ってやれば使えるみたいですが、
大して記述量も変わらないし自力で作った方が良いかも？
インスタンスを生成する処理のメリット
コンストラクタで直接オブジェクトを作るより
new Hoge(1,"aaa");
作るのが面倒でも生成処理に特化したクラスのメソッドで何をしているか表現した方がわかりやすい。
new HogeBuilder().ChangeId(1).ChangeName("aaa").Build();
なんでもかんでもFactoryやBuilderつくりゃ良いというわけでもないけど、
Stairwayパターンの説明の中で
第２章「依存関係と階層化」でStairwayパターンについて説明がある、
そのStairwayパターンの話ではなく、
インターフェースを宣言したアセンブリについて
・アセンブリ外部に依存しない。
・サードパーティーのクラスをメソッド等で提供しない。
・インフラのエンティティへの依存も避ける。
・.Net Frameworkには依存するよね。
というような話がある。
うまく説明は出来ないだろうけどなんとなくわかる。
boolとかIEnumerableとかどんなアセンブリを作ろうが基本ライブラリにはまず依存するだろう。
ただ自作したUserEntityクラスとかサードパーティ製のなんとかクラスとかをインターフェース上にばっちり登場させるとだめですよ。と。
そういったクラスがインターフェース上に登場させたいなら、そのクラスへの依存させないようにインターフェースを作りましょうよ。と。
Entourageアンチパターン
「Ｃ＃実践開発手法」２章でEntourageアンチパターンというのが紹介されていて、
これはインターフェースと実装を同じアセンブリ内に配置しないでね。っていう話みたいだけど、
５章でその例外について触れている。
ただし、このルールには例外が１つあります。それは、インターフェースの依存関係の一部に依存する実装です。
うーん、、、依存関係の一部に依存する実装？？？
後続の文章に「それ以上依存関係が生じない可能性が～」とあるけど、
これはなんだろう、
インターフェースを実装しているけど、そのインターフェース以外に依存関係が増えない作りだったらインターフェースと同じアセンブリに入れていいよってことかな？
DDD-Specificationパターン
DDDのSpecificationパターン（みたいなもの）を書いてみる。
まずは、ISpecificationインターフェース、型パラメータを引数にboolを返す。
型パラメータTには顧客クラスとか請求書クラスとか、Entityがインプットになる。
Entity側でIsなんとかメソッドを大量に実装するんじゃなくて、クラスとして分断し、好きに組み合わせることが出来るようにしましょう。っていうことですね。
書籍ではAND、OR、NOTといった論理演算を閉じた操作で組み合わせることが出来ますが少し違うアプローチで。
まずはAND
OR
そしてNOT
