2016-09-24

WPFのMVVMでコマンドをバインディングする利点

C# VisualStudio

f:id:takamints:20160924175447p:plain
photo credit: Storm Trooper at Oxford via photopin (license)

MVVMパターンでは、ボタンを押した時の処理などは、コマンドにバインディングしましょうということらしく、従来の「Clickイベントをコードビハインドで受けて、、、」というのは嫌われるらしい。

しかし理由なく「MVVMでなきゃダメ！」と言われても納得しがたい。「なぜ？」にはちゃんと答えて欲しいですよね。

ということで、この際きちんと理解しようと頑張りました。

いくつになってもお勉強です。

WHY JAPANESE PEOPLE!? [DVD]

posted with amazlet at 16.09.24

アニプレックス (2015-06-24)
売り上げランキング: 10,600

Amazon.co.jpで詳細を見る

C#実践開発手法 (マイクロソフト公式解説書)

posted with amazlet at 16.09.24

Gary McLean Hall
日経BP社
売り上げランキング: 152,501

Amazon.co.jpで詳細を見る

コマンドの実装例
コマンドを使う利点
コマンド処理のアンチパターン
いくつになってもお勉強

コマンドの実装例

具体的に、コマンドを利用するには

実行したい処理を、ICommandインターフェースを実装したコマンドクラスに記述して、
ビューモデルから、そのインスタンスをプロパティで公開して、
ボタンコントロールのCommand属性からバインディングする

と、これで幸せになれるらしい。

以降、以下の順に実装例を掲載してます。

コマンドクラス：SampleCommand.cs
ビューモデル MainWindowViewModel.cs
ビュー：MainWindow.xaml
ビューのコードビハインド：MainWindow.xaml.cs（おまけ）

コマンド：`SampleCommand.cs`

押してから5秒間、押せなくなるボタンです。やってることは無意味ですが、最低限ICommandインターフェースの全機能を使おうとして長くなってしまいました。

using System;
using System.ComponentModel;
using System.Threading;
using System.Windows.Input;

namespace StudyDotNet.Commands
{
    public class SampleCommand : ICommand
    {
        /// <summary>
        ///忙しいフラグ。忙しい時は何もできません。
        /// </summary>
        private bool _isBusy = false;
        
        /// <summary>
        /// 忙しいフラグのプロパティ。
        /// コマンドが実行可能かどうかに関連するプロパティなので。
        /// 代入されたらCanExecuteChangedイベントを投げる。
        /// </summary>
        public bool IsBusy
        {
            get { return _isBusy; }
            set
            {
                _isBusy = value;
                CanExecuteChanged?.Invoke(this, new EventArgs());
            }
        }

        /// <summary>
        /// 以下でタイマー使っているので、
        /// UIスレッドで画面更新するために必要
        /// </summary>
        private AsyncOperation _uiThreadOperation =
            AsyncOperationManager.CreateOperation(null);
        //
        // 以降 ICommand インターフェースの実装
        //

        public event EventHandler CanExecuteChanged;

        public bool CanExecute(object parameter)
        {
            //忙しくない時だけコマンド実行できる
            Console.WriteLine("実行可否を調べられてる。"
                + (!IsBusy?"お仕事できます":"今無理です"));
            return !IsBusy;
        }

        public void Execute(object parameter)
        {
            //忙しいフラグON
            //一定時間後には暇になる。
            Console.WriteLine("忙しくなるぞー");
            IsBusy = true;
            Timer _busyTimer = new Timer( timerParam => {
                _uiThreadOperation.Post(updatePropParam => {
                    IsBusy = false;
                    Console.WriteLine("暇になった。");
                }, null);
            }, null, 5000, Timeout.Infinite);
        }
    }
}

CanExecuteChangedイベント - コマンドを実行可否の状態変化時に発行するイベント。UIオブジェクトではこのイベントによって、画面表示状態を変更する。なので別スレッドから投げるときは、AsyncOperationでUIスレッドへActionをPostしなくてはなりませんね。
CanExecuteプロパティ - コマンドが実行可能な状況ではtrue、実行できない状況ならfalseを返すプロパティです。
Executeメソッド - コマンドの処理本体です。

ビューモデル `MainWindowViewModel.cs`

ビューモデルは非常にシンプル。上のコマンドクラスのインスタンスをパブリックプロパティとして持ってるだけ。「この画面にはモデルを操作するための、こういう名前のコマンドがありますよ」と。そして「何をするかはコマンドを見て頂戴」というところでしょうか。

using StudyDotNet.Commands;

namespace StudyDotNet.ViewModels
{
    class MainWindowViewModel
    {
        public SampleCommand SampleCommand
        { get; private set; } = new SampleCommand();
    }
}

このプロパティのsetterからは、INotifyPropertyChangedインターフェースを実装して、PropertyChangedイベントを発行すべきだと思い込んでいましたが、なくても動いているようです（ここ、ちょっと理解が曖昧）。

ビュー：`MainWindow.xaml`

ビューからは ButtonのCommand属性からビューモデルのコマンドにバインディング。 ButtonのCommand="{Binding SampleCommand}"の部分ですね。

<Window x:Class="StudyDotNet.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:StudyDotNet"
        xmlns:vm="clr-namespace:StudyDotNet.ViewModels"
        mc:Ignorable="d"
        Title="MainWindow" Height="350" Width="525">
    <Window.DataContext>
        <vm:MainWindowViewModel/>
    </Window.DataContext>
    <Grid>
        <Button x:Name="button" Content="Button"
                Command="{Binding SampleCommand}"
                HorizontalAlignment="Left" Margin="50,50,0,0"
                VerticalAlignment="Top" Width="75"/>
    </Grid>
</Window>

ビューのコードビハインド：`MainWindow.xaml.cs`（おまけ）

ちなみにMainWindowのコードビハインドは、何も触っていません。

using System.Windows;

namespace StudyDotNet
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();
        }
    }
}

コマンドを使う利点

処理をコマンドクラスに記述することで得られる利点は、以下のようなものかと推測します。他にもたくさんありそな気もする。

コードビハインド（*.xaml.cs）に何も書く必要がない。
コマンドの単体テストで、ビューやビューモデルが不要です。

一言でいえば、コマンドの独立性が保たれて、ビューモデルがシンプルに保てます。疎結合はいつでも正義。

コマンドの実行可否がコマンド自体から得られます（CanExecuteプロパティ）し、UIオブジェクトに直結しているので、別途IsEnabledプロパティでバインディングしなくても良いのです。複数の条件が絡み合ったUIオブジェクトが複数ある場合、ビューモデルにIs〇〇ButtonEnabledみたいなプロパティがゴロゴロ沸いてきて煩雑になりやすいですからね。

コマンド処理のアンチパターン

上に書いたように、コマンドには明らかなメリットがありますが、一発で台無しにする方法があります。

それは、コマンドの処理内で昔ながらのメッセージボックスやダイアログを直接モーダル表示することです。

お手軽なので、ついついエラーの表示や問い合わせ等で使いがちですが、よろしくない。

なぜかというとユニットテストが自動ではなくなってしまいます。例えばユーザーがOKボタンを押さないとテストが進まないという事態になります。あとモーダルダイアログとして表示するためにはメインウィンドウが必要なのですが、コマンドの処理の中でメインウィンドウを参照するのもコードの独立性が破れて嫌われます。

コマンド処理内でユーザー入力が必要な場合は、MVVMでの「メッセンジャーパターン」という機構で回避できます。ユニットテストでは簡単に応答を返すスタブに差し替えられます。この「メッセンジャーパターン」については、以下のページに詳しく書いていますので是非。

takamints.hatenablog.jp

いくつになってもお勉強

設計思想的には古くからあるDocument-ViewやMVCなどを最新技術で発展させたもののようですね。

古くはVC++のMFCアプリケーションでメニュー項目などを更新するUpdateUIなどと同じ便利さ加減と思います。便利なんだけどひと手間必要というのも同じですね。当時、あの機構をまともに理解している人が少なくて、往生した覚えがありますわって話が古くて伝わってない？

なにより、「どんな利点があるのか」という観点から、腰を据えて理解できて非常によかった。

フタを開ければかつて知ったる設計思想的な気分でもありました。

やっぱり、いくつになってもお勉強ですねー。

takamints.hatenablog.jp

2016-09-22

C#のラムダ式はAction・Funcと一緒に理解する

C# VisualStudio

f:id:takamints:20160922160154p:plain
photo credit: Imperial Shuttle via photopin (license)

C#のラムダ式をスッキリ理解する方法です。

何事も表面的な丸暗記でなく、基礎からキッチリ理解するほうが結果的には早道ですね。

C#のラムダ式に関しては、ActionクラスととFuncクラスをしっかり理解しておけば、それほど難しくはないはずです。

C#のActionクラスは、戻り値のないメソッドを表すクラスで、Funcは戻り値のあるメソッドです。

どちらもジェネリッククラスで、Actionは引数リスト、Funcは戻り値の型と引数リストをジェネリックパラメータで指定します。

Actionはメソッドの動作内容に注目した名前であり、Funcは数学的な関数として評価値を持つ（＝戻り値がある）ということですね。

この2つのクラスについては以下のページで詳しく書いていますので参照してください。

takamints.hatenablog.jp

C#のラムダ式
ラムダ式は即時呼び出しできません
ラムダ式というランタイムオブジェクトは無い
単なる記法、シンタックス・シュガーです

C#のラムダ式

ルパン三世　ロボット兵ラムダフィギュア　小山田真希　単品

posted with amazlet at 16.09.22

売り上げランキング: 121,062

Amazon.co.jpで詳細を見る

C#逆引きレシピ

posted with amazlet at 16.09.22

arton
翔泳社
売り上げランキング: 97,981

Amazon.co.jpで詳細を見る

ラムダ式の記法的には、以下のような感じ。引数がひとつなら丸かっこは不要とか、波かっこの中身が単一の文なら(複文でないなら)波かっこは要らないとか、いろいろあるんだけど、基本はこちらでOKです。

(name,age) => {
    Console.WriteLine(
        string.Format(
            "{0} is {1} years old",
            name, age));
};

型とか指定されていないし、戻り値ってありなの？無しなの？どうでもいいの？てな具合に、全く情緒が安定しない代物ですが・・・

ラムダ式は即時呼び出しできません

JavaScript的にラムダ式を直接呼び出そうとしてエラーになって「何がダメなの？」と混乱しました。「C#のラムダ式ってJavaScriptの無名関数と一緒でしょ？関数オブジェクトそのものでしょ？」的な思い込みがあったんですね。

でもそれは間違い。C#のラムダ式は、それそのものを呼び出すことができません。

ラムダ式というランタイムオブジェクトは無い

C#のラムダ式は、ActionクラスかFuncクラスのインスタンスを生成するためのものなんですよね。

そもそもこれまで、ラムダ式を見たとき「型が明示されていないのに、どうコンパイルされて実行されているのだ？」と思っていたのですが、正しく動いているコードなら、一見欠落しているように見える引数や戻り値の型情報は、一緒に使われている Action や Func、またはデリゲートで推測可能になってるはず。

ラムダ式はそれらのオブジェクトを生成するために使われるのですが、ランタイムに「ラムダ式」というオブジェクトとして存在しているわけではないということです。

単なる記法、シンタックス・シュガーです

つまり「ラムダ式は、デリゲートやActionやFuncを記述するためのシンタックス・シュガー」であって、それ自体はオブジェクトでもなんでもなく「単なる記法」というわけです。

その証拠に、JavaScriptの即時関数（以下）のようなコードは、C#のラムダ式では実装不可です。コンパイルが通りません。

//JavaScriptの即時関数呼び出し
var a = 1;
(function(b) {
    a += b;
}(2));
console.log("a:", a);// "a: 3"

C#では、一旦Actionのインスタンスを作ってからでないと実行できません。

なぜかというと、ラムダ式だけでは、引数の型が特定できないからなんですね。

以下のコードでは、Actionクラスによって、第一引数がintであることが明示されている(あえて似せて書いていますので無駄に丸かっこが付いています)ので実行可能となるわけです。

int a = 1;
(new Action<int>(b => {
    a += b;
})(2));
Console.WriteLine(string.Format("a: {0}", a));

JavaScriptでの無名関数は関数オブジェクトですが、C#のラムダ式に直接対応するオブジェクトはないってことです。ちなみにJavaのラムダ式は無名クラスのインスタンスなんですね。言語によって扱いが異なるのは興味深いがヤヤコシイ。

2016-08-31

セルの範囲に入力された最も右の値を得るには「MATCH」を使う

表計算 Excel

f:id:takamints:20160831214321p:plain
photo credit: Bailey holding a mug via photopin (license)

セルの範囲内で、最も右の入力された（空白でない）値を得る には、ワークシート関数 MATCH が使えるんですね（INDEXとMAXも使います）。

かれこれ20年以上エクセルを使い続けていますが、今になって新たなワークシート関数を知って感心するとは思ってもいませんでした。長年VBAのマクロでやっていましたが計算式だとお手軽です。そして、このワークシート関数が使えるのはエクセルだけではありません。Google Drive のスプレッドシートでも使えます。以降で実際の Google スプレッドシートを共有していますので、ご利用ください。

事の発端は進捗管理
一番右が欲しいのです
過去の自分にググレカス
MATCHで～す
サンプル（Googleスプレッドシート）

関連記事はこちら↓になります：
takamints.hatenablog.jp

Excel 最強の教科書［完全版］――すぐに使えて、一生役立つ「成果を生み出す」超エクセル仕事術

posted with amazlet at 17.06.24

SBクリエイティブ (2017-01-29)
売り上げランキング: 866

Amazon.co.jpで詳細を見る

事の発端は進捗管理

先日、個人作業の進捗管理のシートを軽い気持ちで作っていたんですね。

縦方向に作業項目を並べて、横方向には当日から締め切りまでの日付が並ぶ。各項目の進捗状況を日毎に記録するものです。

期限内に全作業がきちんと終了するよう自己管理。日々の状況を把握して、対策打ったり、あきらめたり（笑）、ふさぎ込んだり（！？）ってな使い方です。

客観的マネージメントには数値管理が必要ですし、なにより残工数とか表示しちゃって、予測曲線プロットしたりと、もうデータフェチにはたまらない喜びなわけですよ。理解できないかもしれないけど。

たった1日で即戦力になるExcelの教科書

posted with amazlet at 16.08.31

吉田拳
技術評論社
売り上げランキング: 367

Amazon.co.jpで詳細を見る

なぜ、あなたの仕事は終わらないのかスピードは最強の武器である

posted with amazlet at 16.08.31

文響社 (2016-06-08)
売り上げランキング: 19

Amazon.co.jpで詳細を見る

一番右が欲しいのです

作業項目は、1人日（いちにんにち＝一人の人が一日でできる作業）程度に分割しておき、各項目行の日毎のセルに0.5=「今やってます」とか、1.0=「完了した」とか書いていく。

でも、完了したり、そのあと進捗に変化がない日には、同じ数値を入れたくない。手間だし、表としても見にくいし。

なので、各項目の最新の進捗率は、各行の中で、数値が入力されているセルのうち、一番右にあるセルの値を取り出したい。

過去にはVBAのマクロでやってたんですよ。でも入力時のトリガーで再計算とか結構遅くなりますし、別のシートへ展開しにくいんですよね。データ管理用のシートに分けたりしてみましたが、行や列の挿入で簡単に破たんしてしまいます。この辺はホント「エクセルあるある」だと思います。

なので、できれば計算式でやりたいが、そのやり方が分からなかったのです。

なぜ彼女が帳簿の右に売上と書いたら世界が変わったのか?

posted with amazlet at 16.08.31

衛藤美彩澤昭人
PHP研究所
売り上げランキング: 369

Amazon.co.jpで詳細を見る

Microsoft Excel 2016(最新)|オンラインコード版

posted with amazlet at 16.08.31

マイクロソフト (2015-09-30)
売り上げランキング: 20

Amazon.co.jpで詳細を見る

過去の自分にググレカス

で、この度ググってみたら以下のサイトが見つかった。

EXCELで、範囲指定した一番右の数値(セル)を返す関数ってありますか？...-Yahoo!知恵袋
detail.chiebukuro.yahoo.co.jp

というか他にもゴロゴロ出てきますやん。しかもそれぞれ、結構古くて2009年とか、7年前の情報です。

なんで今まで検索しなかった？と不思議でしたが、よくよく思い出してみると、ちょうどワタシが管理業務から~~逃れた~~離れることになった時期。当時、このような管理面のことを、（一時的に）ちっとも考えなくなっていたんだな。ダメですね。

MATCHで～す

マッチ箱の脳(AI)―使える人工知能のお話

posted with amazlet at 16.08.31

森川幸人 (2014-01-05)
売り上げランキング: 1,343

Amazon.co.jpで詳細を見る

モノワイヤレス TWE-001L-DIC-WA TWE-Lite DIPシリーズ端子付き(マッチ棒アンテナ)

posted with amazlet at 16.08.31

モノワイヤレス(Mono Wireless)
売り上げランキング: 26,668

Amazon.co.jpで詳細を見る

まあ、とにかく、そこで紹介されているのは、以下のような計算式でした。

セル範囲A1:E1に入力されてる最も右の値を得る:

= INDEX ( A1:E1, MATCH( MAX(A1:E1) + 1, A1:E1, 1 ))

INDEX関数

INDEX関数は、セル範囲からインデックスを指定して値を得る関数です。第一引数がセルの範囲で、第二引数がインデックス。上の式ではA1:E1がセル範囲。MATCH( ... )がインデックスですね。

MATCH関数

で、INDEXの第二引数に指定されてるMATCH関数は、一次元のセル範囲（つまり1行か1列）から検索値にマッチする値が入力されたセルの位置（インデックス）を返す関数です。第一引数が検索値、第二引数がセルの範囲、第三引数が検索の型。

MAX関数

その名の通り、範囲内から最大値を得る関数ですね。

ちょっと待って、なんで最大値を探すのだ？

しかしちょっと待ってくださいよ、上の例では、検索値が、MAX(A1:E1)+1となっていて、セル範囲内の最大値+1となっているではないですか。これ検索してもダメなんじゃ？！と思ったのですが、どうやらミソは第三引数の検索の型。検索の型が1だと、検索値以下の最大値にヒットするのだとか。（だから本来+1する必要はないのだと思います）。しかも省略時のデフォルトが1なので省略してもよいみたい。

まだワカラン。一番右が最大だとは限らんのでは？

しかしまだ、納得できない。釈然としない。最大値の位置を知っても、それが一番右にあるとは限らないのだから、これでは目的の値は得られないのでは？と疑いましたが、なんとMATCH関数の説明に、セル範囲内のデータは昇順にソートされている前提と書かれているんですね。

エクセルのヘルプでは、たまにこういった軽く意味不明の記述がありまして、見るたびに「なんちゅう都合のいい仕様？！www」と嘲笑とか憤慨を覚えていました。

しかし、どうやら、この前提のおかげで、最後まで検索してくれるよう。こういう目的で使いたいから、こんな妙な前提を入れているのかなとか思ったりもしたがはて？。

サンプル（Google スプレッドシート）

以下に、Googleスプレッドで作ったサンプルを埋め込んでいますが計算式が読めないのでこちらからどうぞ。

2016-07-30

最近気づいたVisualStudio 2015 C# で便利に使える5つの機能

VisualStudio C# 開発環境

全国的に梅雨も明け、本格的な夏ですね。自分的には（仕事で）年に一度の恒例のVisualStudioシーズン・イン。昨年までは冬場が多く、期間は長くても2か月程度。しかし今年は 6月初めから徐々に動き出して、7月以降に本格化。期間はトータル4、5か月になりそうです。終わるころには秋ですね。

例年そんなインターバルでやっているので、VisualStudioやC#の、最新開発状況（環境やプログラミングスタイルなど）になかなか追従できていないのですが、今回は多少期間が長いため、視野がちょっとだけ広くなったか「あ、こんなことができるんだあ」とか「こんな風に書けるのねー」みたいなことが何度かありましたので書いておきます。

あくまでも、自分が知らなくて最近気が付いたってことですので、皆さんご存知なことばかりかも。しかし、いくつになってもお勉強。新知識には興奮します。

f:id:takamints:20160730125037p:plain

メニュー

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

posted with amazlet at 16.07.30

日経BP社 (2015-06-25)
売り上げランキング: 2,683

Amazon.co.jpで詳細を見る

なぜ、あなたの仕事は終わらないのかスピードは最強の武器である

posted with amazlet at 16.07.30

文響社 (2016-06-08)
売り上げランキング: 42

Amazon.co.jpで詳細を見る

1. プロパティ名を指定せずOnPropertyChangedを呼ぶ

INotifyPropertyChangedを実装したクラスのプロパティに値を設定されたとき、PropertyChangedイベントを発生させますが、これまで以下のようにプロパティ名を文字列で指定して、OnPropertyChangedメソッドを呼び出していました。律儀にね。

using System.ComponentModel;
namespace Application {
  class ViewModel: INotifyPropertyChanged {
    public event PropertyChangedEventHandler PropertyChanged;
    public virtual void OnPropertyChanged(string name) {
      if(PropertyChanged != null) {
        PropertyChanged.Invoke(this, new PropertyChangedEventArgs(name));
      }
    }
    private int _propFoo;
    public int PropFoo {
      get { return _propFoo; }
      set {
        _propFoo = value;
        OnPropertyChanged("PropFoo");
      }
    }
  }
}

ところが、プロパティが増えると、そのうち必ず間違えるでしょう？それに、名前を変えたら文字列も変えなきゃならないわけで。多分おそらく、やってられないですよコレは。

そこで、

`[CallerMemberName]`を使いましょう

Call Me Maybe

posted with amazlet at 16.07.30

Universal Music LLC (2014-02-03)
売り上げランキング: 135

Amazon.co.jpで詳細を見る

以下のように、OnPropertyChangedメソッドの、プロパティ名称を受け取る文字列引数を、省略可能（既定値は空文字列）にして、[System.Runtime.CompilerServices.CallerMemberName]属性を設定しておくと、引数を省略して呼び出しても、呼び出し元のプロパティ名（以下の例では"PropFoo"）が自動的に渡されるのです。

using System.ComponentModel;

namespace Application {
  class ViewModel: INotifyPropertyChanged {
    public event PropertyChangedEventHandler PropertyChanged;

    // CallerMemberNameアトリビュートを名前を受け取る文字列引数に指定する。
    public virtual void OnPropertyChanged(
      [System.Runtime.CompilerServices.CallerMemberName]
      string name = "")
    {
      if(PropertyChanged != null) {
        PropertyChanged.Invoke(this, new PropertyChangedEventArgs(name));
      }
    }
    private int _propFoo;
    public int PropFoo {
      get { return _propFoo; }
      set {
        _propFoo = value;

        //引数を省略して呼び出すと、このプロパティ名"PropFoo"が渡される
        OnPropertyChanged();
      }
    }
  }
}

これなら、リファクタリングし放題ですねっ。

※ 上の例では、あえて冗長に属性名をフルパスで書いていますが、実際の局面では、いきなり[CallerMemberName]と書いてから（この時点ではコンパイルエラーかも）、[Ctrl]+[.]で、using System.Runtime.CompilerServicesを追加すれば良いですよ。

つまり呼び出し元のメンバ名が渡される

ここの例では、プロパティから呼び出しているのでプロパティ名になっていますが、メソッドから呼び出せば、そのメソッド名が渡されます。 CallerMemberNameの名のとおり、呼び出した側のメンバ名が渡される。

本来イベントとは何の関係もない機能ですが、気付くきっかけが「OnPropertyChangedじゃまくせー」と思って調べていた時だったのでこうなった。デバッグログを出力するような場合にも有用でしょうね。

2. nullチェックの簡略記法

塗る!! PUZZLE&DRAGONS 超精密塗り絵

posted with amazlet at 16.07.30

KADOKAWA/エンターブレイン (2016-02-19)
売り上げランキング: 38,291

Amazon.co.jpで詳細を見る

if文でオブジェクトがnullでないことを確認してから、そのメソッドを呼び出す処理は、さらにシンプルに書けます。一つ上の例では、イベントのリスナーがいるかどうかを確認しています（以下に抜き出してます）

    public event PropertyChangedEventHandler PropertyChanged;
    public virtual void OnPropertyChanged(string name) {
      if(PropertyChanged != null) {//←ここ
        PropertyChanged.Invoke(this, new PropertyChangedEventArgs(name));
      }
    }

長年「こういうものだ」と思っていたので特に不便さは感じていませんでしたが、最近のC#では、以下のように?を使って短く書ける。知ってしまうともう戻れない。

    public event PropertyChangedEventHandler PropertyChanged;
    public virtual void OnPropertyChanged(string name)
    {
      PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
    }

対象のオブジェクト（上の例ではPropertyChanged）がnullでないならそのままメソッドを呼び出しますが、nullなら何も行わない。

最初、「え？」と思いました。そういえばnull許容型で似た記述をしますが、三項演算子の発展形（省略形？）のようにも思えます。

これは、メソッド呼び出しのための構文ではなく対象オブジェクトがnullかどうかによって、その後のメンバーの参照をするかどうかということです。そして、以下のようにチェーンできますから、オブジェクトの階層が深い場合は、かなり有利。途中のプロパティやメソッドの戻り値がnullなら、nullとして評価され、それ以降は評価されないということですね（多分）。

  Foo?.Bar?.Baz()?.Hoge("Fuga");

メッチャ強力。過去のコードを修正したくなりますね（しないけど）。いやしかし、こりゃ楽でいい。

3. 自動実装プロパティの初期値設定

すごい手抜き - 今よりゆるくはたらいて、今より評価される30の仕事術 -

posted with amazlet at 16.07.30

ワニブックス (2016-04-11)
売り上げランキング: 18,445

Amazon.co.jpで詳細を見る

地味ではあるけど、これも由。

自動実装プロパティに特定の初期値を与えるためには、以下のように、コンストラクタで値を設定しなくてはならなかったと思っていましたが、

//従来の自動実装プロパティを持つクラス
class Foo {
  public int Bar { get; set; }
  public Foo() {
    Bar = 999;
  }
}

プロパティ宣言部分で値を設定できる（以下）ようになっていました。

//最新式（笑）の自動実装プロパティを持つクラス
class Foo {
  public int Bar { get; set; } = 999;
}

これも楽です便利です。

自動実装で楽しているにもかかわらず、コンストラクタを別途定義するとかアホちゃうかと潜在的に思っていましたが、やっと報われた（謎）。

4. 読み出し専用プロパティを自動実装

Verbatim バーベイタム 128GB UHS-I microSDHCカードフルHD 高速ビデオ SDアダプター付く(最大読出スピード:300X - 45MB/s)

posted with amazlet at 16.07.30

VERBATIM CORPORATION
売り上げランキング: 79,718

Amazon.co.jpで詳細を見る

もうひとつ自動実装プロパティネタ。

GetterがパブリックでSetterはプライベートというプロパティは自動実装できないものだと思い込んでいて、常々以下のように書いていました。

class Foo {
  private int _bar = 999;
  public int Bar { get { return _bar;} }
}

でも、以下のように書けるのだとか。

class Foo {
  public int Bar { get; private set; } = 999;
}

これは、自分が知らなかっただけかな。

5. 自動実装プロパティのスニペットを挿入する

プロパティを新設するとき、全部自分でキー入力していましたが、エディタでpropと入力して、[Tab]を2回叩けば、とりあえずint型のMyPropertyという自動実装プロパティが挿入されますね。

ほかにも便利なスニペットがあるかもしれん。いろいろ探し歩いてみます。

ポケモンGO ポケモンゴー攻略ゲット - WiLLBee CLIPON (黒) Pokemon Go スマホハンドバンドホルダーリング - Xperia iPhone 6S 6 Plus

posted with amazlet at 16.07.30

WiLLBee Japan
売り上げランキング: 4,385

Amazon.co.jpで詳細を見る

Anker PowerCore 10000 (10000mAh パナソニックセル搭載最小最軽量* 大容量モバイルバッテリー) iPhone / iPad / Xperia / Android各種他対応マット仕上げ【PowerIQ & VoltageBoost搭載】*2016年1月末時点 A1263011

posted with amazlet at 16.07.30

Anker
売り上げランキング: 14

Amazon.co.jpで詳細を見る

2016-07-28

Visual Studio 2015 Update 3 適用でテストウィンドウに例外発生 ⇒ 言語設定を英語にすれば治りますけど・・・

VisualStudio 開発環境

何も考えずに更新プログラムとか適用しちゃうの良くないねってな典型的なことをやらかしちゃって、お恥ずかしい限りですけど、書いておきます。

いくつになってもお勉強です。

f:id:takamints:20160727235358p:plain

2016-08-03 追記：Update 3へのパッチが本日適用可能になっており、日本語環境でのテストウィンドウの例外は解消しました。結果的には問題なかったのですが、インストール直後のVisual Studioの起動が大変遅く、日本語に切り替えてからは、三回ぐらい、ソリューションの読み込みが「応答なし」で失敗しました。しかし、この現象はパッチの影響ではないかもしれません。Windows 10の「Antimalware Service Executable」の問題と関連していたかも。

要約すると

VisualStudio Community 2015の日本語環境に Update 3 を適用。
ソリューションを開くとテストウィンドウの初期化時エラー。ユニットテストが表示されない。
日本語環境では回避不能。言語設定を英語にすればエラーは発生しないようです。

ということで、本質的な解決にはなっていませんが、エラーの内容や、対処手順を以下に書いておきました。

作って覚えるVisual C# 2015 デスクトップアプリ入門

posted with amazlet at 16.07.27

荻原裕之宮崎昭世
秀和システム
売り上げランキング: 3,310

Amazon.co.jpで詳細を見る

C#実践開発手法　デザインパターンとSOLID原則によるアジャイルなコーディング

posted with amazlet at 16.07.27

日経BP社 (2015-06-25)
売り上げランキング: 1,065

Amazon.co.jpで詳細を見る

発生した現象

VisualStudio Community 2015で、ソリューションを開くと「Update 3が利用可能」と通知され、普段からあまり何も考えていないので、つい更新しちゃったのですが、その後、ソリューションを開いたら以下のメッセージが表示されてダメだこりゃ。

パーツ "Microsoft.VisualStudio.TestWindow.UI.TestWindowToolWindowControl" の初期化中に例外がスローされました。

画面はこちら
f:id:takamints:20160728002628p:plain

なんと、ユニットテストのウィンドウの中身（テストの一覧が表示されるところ）が空っぽですよ。ダメじゃないかVisualStudio。

「全てのテストを実行」しても、結果がわからないどころか、本当に実行されているかどうかも分からない。

言語設定を英語にすれば回避可能、だが・・・

エラーメッセージ（↑）丸ごと検索で、たった一件、Visual Studioのページがヒット。どうやら日本語環境では不可避なようです。で、英語版なら大丈夫だと。

仕方がない。とりあえず「英語版に切り替えよう」と、メニューバーから[ツール]-[オプション]でオプションダイアログ表示して、左側のツリーから[環境] > [国際対応]とポイント、右の[言語]ドロップダウンから[英語]・・・

f:id:takamints:20160727231040p:plain

選べないです。そういうもんなんですね。日本語パックを外せば英語になるのかと思ってましたが違ってました。

そこで英語の言語パックをダウンロードしてインストール

面倒だけど同ダイアログの「追加の言語を取得する」というリンクをクリックして、

f:id:takamints:20160727231530p:plain

ドロップダウンから「英語」を選び（ページが更新されます）

f:id:takamints:20160727232205p:plain

Downloadをクリックして、

f:id:takamints:20160727232225p:plain

ダウンロードされたvs_langpack.exeを実行してから画面に従いインストール。

f:id:takamints:20160727232503p:plain

LanguageをEnglishにChangeすると

やっとこ、オプションダイアログで言語のコンボから、「English」が選べるようになりましたよっと。

f:id:takamints:20160727234104p:plain

そして、VisualStudio 再起動。

あらおめでたい

英語だ英語だ・・・ f:id:takamints:20160727234643p:plain

確かにエラーは出ませんでした。
f:id:takamints:20160728002748p:plain

しかしだよ

全部英語で表示されると若干（かなり）使いにくい。感覚的に操作できないというか、ずらりと表示されるコンテキストメニューとか、目を皿のようにして一生懸命読まないといけない感じ。人間の視覚と言語って密接にかかわっているのだなあと感心しますが、なによりこのバグ治ってほしいわ。

その他

あと、言語設定に関係ないですけど、自分の中でも未確認情報ですが Update 3を入れた後、ビルド実行やデバッグ実行に失敗したりしなかったりと、統合環境の動作が不安定な気がします。よくわからないですけどね。←これはワタシが入れたバグでした（参照しているlog4netのバージョン違いでstaticコンストラクタが失敗とかorz.）

Update 3 では、Update 2でのメモリの大量使用が改善されているようで、なんとなく起動が早い気がします（スプラッシュ画面だけ延々表示されてる時間が短い）。ユニットテストをしない人や、英語に違和感がない人は、気にせず更新すれば幸せかもしれません。

参考サイト

こちらもどうぞ ― Visual Studio / C# / WPF 関連記事

takamints.hatenablog.jp

コマンドの実装例

コマンド：SampleCommand.cs

ビューモデル MainWindowViewModel.cs

ビュー：MainWindow.xaml

ビューのコードビハインド：MainWindow.xaml.cs（おまけ）

コマンドを使う利点

コマンド処理のアンチパターン

いくつになってもお勉強

C#のラムダ式

ラムダ式は即時呼び出しできません

ラムダ式というランタイムオブジェクトは無い

単なる記法、シンタックス・シュガーです

事の発端は進捗管理

一番右が欲しいのです

過去の自分にググレカス

MATCHで～す

INDEX関数

MATCH関数

MAX関数

ちょっと待って、なんで最大値を探すのだ？

まだワカラン。一番右が最大だとは限らんのでは？

サンプル（Googleスプレッドシート）

[CallerMemberName]を使いましょう

つまり呼び出し元のメンバ名が渡される

発生した現象

言語設定を英語にすれば回避可能、だが・・・

そこで英語の言語パックをダウンロードしてインストール

LanguageをEnglishにChangeすると

あらおめでたい

しかしだよ

その他

参考サイト

コマンド：`SampleCommand.cs`

ビューモデル `MainWindowViewModel.cs`

ビュー：`MainWindow.xaml`

ビューのコードビハインド：`MainWindow.xaml.cs`（おまけ）

サンプル（Google スプレッドシート）

`[CallerMemberName]`を使いましょう