OpenCVの画像処理をお手軽に ― OpenCVフィルター処理ライブラリ cvImagePipeline のご紹介
OpenCVの画像処理をお手軽にできるC++向けフィルター処理ライブラリ cvImagePipeline のご紹介。
画像処理の流れや各モジュールのパラメータの指定をXMLで記述できますので、画像処理の処理順の変更やパラメーター調整作業がはかどります。 複数のフィルターを組み合わせて独自のフィルターも作れます。
背景除去のサンプルプログラム
以下の画像は、ライブラリに含まれているサンプルプログラムの実行中画面です。
単純な背景除去の実装実験を行っている画面です。 入力画像や前処理中の画像などを、6分割した画面に統合して表示しています。 (カメラ入力や画面の分割、Window表示もそれぞれ、このライブラリのフィルターです。)
左上から順に、
- キャプチャ画像(の鏡像)
- 1をグレイスケールに変換
- 2に対して、ヒストグラム均一化とガウシアンブラーを適用
- 3の過去18000フレーム分を平均
- 3と4の差分(絶対値差分)
- 5の二値化
このあと、6の二値化画像に対して、膨張(dilate)と縮小(erode)を適当に繰り返してから元画像(1の画像)をマスクすれば背景と前景に分離できそうです。
処理は全てsample.xml
(↓)に記述しており、参考として下に掲載しているC++のコード(capture.cpp
)で読み込んで処理させています。
このためビルド無しで処理を変更可能です。(XMLを読み込む処理は複数のフィルターをまとめるImgProcSet
の機能です)
sample.xml
- 背景除去するXML
<cvImagePipeline name="testProcessor"> <Processor class="VideoCapture" name="cap"> <Property name="deviceIndex" value="0"/> </Processor> <Processor class="Flipper" name="fripHoriz"> <Property name="flipDir" value="1"/> </Processor> <Processor class="ImagePoint" name="raw"/> <Processor class="ColorConverter" name="grayscale"/> <Processor class="EqualizeHist" name="equalizeHist"/> <Processor class="GaussianBlur" name="blur"/> <Processor class="DepthTo32F" name="depth32F"/> <Processor class="ImagePoint" name="pp"/> <Processor class="RunningAvg" name="background"> <Property name="averageCount" value="18000"/> </Processor> <Processor class="AbsDiff" name="diff" autoBind="false"> <Input to="src1" from="pp"/> <Input to="src2" from="background"/> </Processor> <Processor class="Convert" name="to8UC"> <Property name="rtype" value="0"/> <Property name="alpha" value="255"/> <Property name="beta" value="0"/> </Processor> <Processor class="Threshold" name="binary"> <Property name="type" value="CV_THRESH_BINARY"/> <!-- CV_THRESH_BINARY CV_THRESH_BINARY_INV CV_THRESH_TRUNC CV_THRESH_TOZERO CV_THRESH_TOZERO_INV --> <Property name="otsu" value="1"/> <Property name="thresh" value="50"/> <Property name="maxval" value="255"/> </Processor> <Processor class="FitInGrid" name="integratedImage" autoBind="false"> <Property name="width" value="960"/> <Property name="height" value="480"/> <Property name="cols" value="3"/> <Property name="rows" value="2"/> <Property name="interleave" value="0"/> <Input to="0" from="raw"/> <Input to="1" from="grayscale"/> <Input to="2" from="blur"/> <Input to="3" from="background"/> <Input to="4" from="diff"/> <Input to="5" from="binary"/> </Processor> <Processor class="ImageWindow" name="window"> <Property name="windowName" value="cvImagePipeline"/> <Property name="showFPS" value="1"/> </Processor> </cvImagePipeline>
capture.cpp
- XMLを処理するプログラム
#include "stdafx.h" #if defined(_MSC_VER) #include <windows.h> #else #include <unistd.h> #define Sleep(millisec) usleep(millisec * 1000) #endif #include <opencv2/opencv.hpp> #include "cvImagePipeline.h" using namespace cvImagePipeline; using namespace cvImagePipeline::Filter; #if defined(_MSC_VER) int _tmain(int argc, _TCHAR* argv[]) #else int main(int argc, char* argv[]) #endif { cvInitSystem(argc, argv); ImgProcSet processors; std::string xml_filename("sample.xml"); if (argc > 1) { xml_filename = argv[1]; } if (!processors.loadXml(xml_filename)) { std::cerr << "ファイル読み込み失敗 ファイル名:" << xml_filename << std::endl; return -1; } Sleep(2000); while(true) { processors.execute(); int ch = cvWaitKeyEx(1); if (ch == '\x1b') { fprintf(stderr, "exit.\n"); break; } } cvDestroyAllWindows(); return 0; }
リポジトリ
上の例も含めて、その他詳細は下記リポジトリのREADMEを参照してください。
実を言うと、このリポジトリ、1年以上放置しているんですねえ。 しかし今でも Clone してくださる方が月に数人いらっしゃるようです。 READMEが古くなっていて申し訳ないですから、これを機にキチンとメンテしようと思ってはいますが・・・。
そういや以下の記事でもシレッと使っていますねw
今後の課題
今考えつく今後の課題は以下の様なことです。放置している場合ではないなあ。
- OpenCV 3.0以上での動作確認。
- Windows 10 での動作確認。
- 基本フィルタと他のサンプルフィルタの分離。
- 追加実装のしやすさを追求。
- XMLをXAML的文法に変更(記述量を少なくできそう)。
- XMLのビジュアルな編集。
- デバッグ機能の充実。
- 実行中のフィルタのバイパスやパラメータの変更機能。
- Pythonから利用できるインタフェース。C++はやっぱり敷居が高いかも。
- 妙に凝った変な名称のフィルタを改名するw
まだ間に合うXAMLの基本
「XAMLはなんだか複雑だ」と思ってました。
しかし、あることに気が付いてから「なかなかシンプルなんじゃない?」と思えるようになりました。
ちゃんと知っている方にとっては、当たり前のことかと思いますが、その「ちょっとしたこと」を出発点に、1段掘り下げて調べた結果を書いておきます。
photo credit: Doug Kline Star Wars Celebration IV - X-Wing fighter (back) via photopin (license)
- XAML要素でインスタンスが生成される
- 属性でパブリックプロパティを設定する
- プロパティへクラスオブジェクトを代入する
- 静的クラスのプロパティへオブジェクトを代入する
- そもそも子要素は何処に格納されるのか
1. XAML要素でインスタンスが生成される
XAMLの要素名はクラス名で、実行時には、そのクラスのデフォルトコンストラクタでインスタンスが生成される。
クラス名であることは知っていましたが、デフォルトコンストラクタで生成されるという認識がありませんでした。 だから実行時のオブジェクトの状態を正確に把握できていなかったんですわ。
MainWindow.xaml(MVVM的に真っ当にMessageBoxを表示する - 銀の弾丸より)
<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" xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" xmlns:tr="clr-namespace:StudyDotNet.Triggers" mc:Ignorable="d" Title="MainWindow" Height="350" Width="525"> <Window.DataContext> <vm:MainWindowViewModel/> </Window.DataContext> <i:Interaction.Triggers> <tr:MessageBoxTrigger> <tr:MessageBoxAction /> </tr:MessageBoxTrigger> </i:Interaction.Triggers> <Grid> <Button x:Name="button" Content="Button" Command="{Binding SampleCommand}" HorizontalAlignment="Left" Margin="50,50,0,0" VerticalAlignment="Top" Width="75"/> </Grid> </Window>
takamints.hatenablog.jp
上のXAMLでは、次のクラスオブジェクトが生成されています。 (ドットを含む要素名と、子要素の所在については後述します)
- MainWindowViewModel
- MessageBoxTrigger
- MessageBoxAction
- Grid
- Button
確かにビューモデルやボタンなどは、実行時に生成されていて、コードビハインドからアクセスできますよね。 でも、デフォルトコンストラクタとの関連は想像していなかったんです。 このような、標準の部品に関しては、.NETフレームワーク内で特別なことが行われているのだろう・・・などと思ってました。
でも、自作クラスも生成されてるってことは・・・という段になって、やっと気付いた。
思った以上にシンプルですね。そもそもフレームワークをそんなガチガチに作るわけ無いですし。
2. 属性でパブリックプロパティを設定する
売り上げランキング: 190,062
要素の属性はそのクラスオブジェクトのパブリックプロパティへの代入です。 デフォルトコンストラクタで生成されたのち、プロパティが設定されます。
属性値として直接記述できるのは、文字列とか数値といったプリミティブな型に制限されると思います。 バインディングの解決は、少し複雑なことがなされているのかもしれませんね。
3. プロパティへクラスオブジェクトを代入する
ところで、XAMLでデータコンテキストを生成しているところ(以下)。
<Window x:Class="StudyDotNet.MainWindow" ~中略~ > <Window.DataContext> <vm:MainWindowViewModel/> </Window.DataContext> ・ ・ ・ </Window>
この Window.DataContext要素のように、親エレメント.プロパティ名
という要素は、親要素のインスタンスプロパティへの代入なんですね。
つまりここでは、MainWindow
クラスの基本クラスであるWindow
のDataContext
プロパティへ、MainWindowViewModel
のインスタンスを設定(Property Set)しているということです。
4. 静的クラスのプロパティへオブジェクトを代入する
以下のInteraction.Triggers
も似ていますが、ドットの前がInteractionとなっていて、親要素ではありません。
これは、System.Windows.Interactivity.Interaction
というスタティッククラスで、そのTriggers
というプロパティにMessageBoxTrigger
を追加しています。
<Window x:Class="StudyDotNet.MainWindow" ~中略~ > ・ ・ ・ <i:Interaction.Triggers> <tr:MessageBoxTrigger> <tr:MessageBoxAction /> </tr:MessageBoxTrigger> </i:Interaction.Triggers> ・ ・ ・ </Window>
ところが Interaction
クラスにそのものスバリのTriggers
というプロパティはありません。
かわりにTriggerCollection GetTriggers(DependencyObject obj)
というメソッドがありますので、XAMLのパーサーがうまくやってくれているのだと思います(詳細不明)。
以下のように、コードビハインドからthis
を与えて返されるコレクションに、ちゃんとMessageBoxTrigger
のインスタンスが入っていました。
using System; using System.Windows; using System.Windows.Interactivity; namespace StudyDotNet { /// <summary> /// Interaction logic for MainWindow.xaml /// </summary> public partial class MainWindow : Window { public MainWindow() { InitializeComponent(); var triggers = Interaction.GetTriggers(this); foreach(var trigger in triggers) { Console.WriteLine(trigger.GetType().Name); } } } }
ちなみにInitializeComponent
の前では何も表示されなかったので、XAMLはInitializeComponent
で処理されているのでしょう。
5. そもそも子要素は何処に格納されるのか
XAMLのパーサーは、子要素のインスタンスを親要素の何処に格納するの?という疑問。 コレクションであることは間違いなさそうなのですが。
XAMLの以下の部分などですね。
<i:Interaction.Triggers> <tr:MessageBoxTrigger> <tr:MessageBoxAction /> </tr:MessageBoxTrigger> </i:Interaction.Triggers>
「XAMLのパーサーが、MessageBoxTriggerのインスタンスに、MessageBoxActionのインスタンスを保持させている」ということは明らか。
実際にアクションはイベントトリガーのActionsというコレクションプロパティに保持されており、 このプロパティは、MessageBoxTriggerの基本クラスであるTriggerBaseに実装されています。 でも、XAMLだけを見る限りは、そんな事実はわからない。
ということで、System.Windows.Interactivity.TriggerBaseの説明を見てみると、以下のようになっています。
[ContentPropertyAttribute("Actions")] public abstract class TriggerBase : DependencyObject, IAttachedObject
なるほど、ContentPropertyAttributeで「XMLのコンテントはプロパティ名 Actions に」と読めますね。 XAMLのパーサーはこの宣言に従って子要素を親要素に格納している。
ということで、Interaction.Triggersの中身を、以下のように冗長に書き換えても同じように動作します。
<i:Interaction.Triggers> <tr:MessageBoxTrigger> <tr:MessageBoxTrigger.Actions> <tr:MessageBoxAction /> </tr:MessageBoxTrigger.Actions> </tr:MessageBoxTrigger> </i:Interaction.Triggers>
まとめと所感
このように、曖昧に済ませていたことを深掘りしてみて、かなりスッキリ気分爽快。 XAMLで何でもできる気がしてきました。
基本を押さえるのはホントに大切。 知識やスキルを習得するときの効率性に直結しますね。
いくつになってもお勉強です。
MVVM的に真っ当にMessageBoxを表示する
photo credit: waterj2 DSCF0629 via photopin (license)
MVVM的に正しくモーダルなメッセージボックスを表示するサンプルコードを示します。
WPFでのMVVMパターンとしては、ビュー以外からメッセージボックスを直接表示するのは良くないらしいです。
メッセージボックスで親ウィンドウを指定しないとモーダルにならないのですが「ビュー以外からメインウィンドウを逆方向へ参照するのは悪手」ということです。
じゃあ、どうすればよいかっていうと「メッセンジャーパターン」を使いましょうとのことでした。
「メッセンジャーパターン」て?
メッセンジャーパターンは「VMからViewを操作する方法」のことらしいです。 以下のようなカラクリだと理解しました。
- 「メッセンジャー」というオブジェクトからイベントを発行して、
- あらかじめビューに実装されたイベントトリガーが、このイベントを受けて、
- イベントトリガーが保有するトリガーアクションが処理をする(イベントの引数も渡される)。
上に書いた点を自分なりに整理して、ややこしいことを抜きで System.Windows.MessageBox と同じように使えるコードをご紹介します。 GitHub Gistにも置いていますのでご自由にご利用ください。
コードの概要
ここで、
- メッセンジャーは単なるクラス。
- イベントトリガーは、System.Windows.Interactibity.EventTriggerの派生クラス。
- トリガーアクションは、System.Windows.Interactibity.TriggerAction
の派生クラス。
※ System.Windows.Interactibityは、プロジェクトから参照されていないかもしれません。 参照マネージャの左のツリーから[アセンブリ]/[拡張]を開いてチェックを付ければOKです。
1.メッセンジャーとイベントトリガー(これが本体)
内部クラスを含めて3つのクラスを定義しています。System.Windows.MessageBoxと同じように使えるようにしたら長くなりました。
- MessageBox - メッセンジャー。スタティックなShowメソッドでシングルトンのインスタンスからイベントを発行。
- MessageBox.Action トリガーアクションの抽象基底クラス。実際にメッセージを表示するクラスの基本クラスです。
- MessageBoxTrigger - イベントトリガークラス。MessageBoxからのイベントを受け取って、トリガーアクションを実行します。
MessageBoxTrigger.cs
using System; using System.Linq; using System.Windows; using System.Windows.Interactivity; namespace StudyDotNet.Triggers { /// <summary> /// MVVM的メッセージボックスを表示するためのメッセンジャー。 /// /// MessageBox.Showメソッドで、イベントトリガーを起動する。 /// /// 実際の表示は、イベントトリガーから実行される /// トリガーアクションに実装される。 /// </summary> public class MessageBox { /// <summary> /// MessageBoxTriggerを起動するイベント。 /// </summary> public event EventHandler<EventArgs> ShowMessageBox; /// <summary> /// MessageBoxTriggerを起動するイベントの名前。 /// </summary> public static string EventName { get { return "ShowMessageBox"; } } /// <summary> /// このクラスはシングルトン。 /// </summary> public static MessageBox Instance { get; private set; } = new MessageBox(); private MessageBox() { } /// <summary> /// MessageBoxTriggerを起動するイベントの引数。 /// トリガーアクションへ渡されて処理される。 /// </summary> public class EventArgs : System.EventArgs { public string Text { get; set; } public string Title { get; set; } public MessageBoxButton Button { get; set; } public MessageBoxImage Icon { get; set; } /// <summary> /// メッセージボックスの結果を受け取るコールバック /// </summary> public Action<MessageBoxResult> NotifyResult { get; set; } } /// <summary> /// MVVM的メッセージボックスを表示。 /// 実際にはイベントを発行してイベントトリガーを起動する。 /// </summary> /// <param name="messageBoxText"></param> /// <param name="title"></param> /// <param name="button"></param> /// <param name="icon"></param> /// <returns></returns> public static MessageBoxResult Show( string messageBoxText, string title = null, MessageBoxButton button = MessageBoxButton.OK, MessageBoxImage icon = MessageBoxImage.Information) { //メッセージボックスの結果 MessageBoxResult messageBoxResult = MessageBoxResult.Cancel; //イベントを発行する Instance.ShowMessageBox?.Invoke( Instance, new MessageBox.EventArgs() { Text = messageBoxText, Title = title, Button = button, Icon = icon, //コールバックで結果を受け取る NotifyResult = result => { messageBoxResult = result; } }); //メッセージボックスの結果を返す return messageBoxResult; } /// <summary> /// メッセージを表示するトリガーアクション実装用の抽象基底クラス。 /// /// 派生クラスでShowMessageを実装する。 /// </summary> public abstract class Action : TriggerAction<DependencyObject> { /// <summary> /// アクションの実態 /// </summary> /// <param name="parameter"></param> protected override void Invoke(object parameter) { //イベント引数の種別を検査 var messageBoxArgs = parameter as MessageBox.EventArgs; if(messageBoxArgs == null) { return; } //メッセージボックスの表示結果を取得 MessageBoxResult result = ShowMessage( messageBoxArgs.Text, messageBoxArgs.Title, messageBoxArgs.Button, messageBoxArgs.Icon); //コールバックで結果を通知 messageBoxArgs.NotifyResult?.Invoke(result); } /// <summary> /// メッセージボックスを表示する抽象メソッド。 /// </summary> /// <param name="text"></param> /// <param name="title"></param> /// <param name="button"></param> /// <param name="icon"></param> /// <returns></returns> abstract protected MessageBoxResult ShowMessage( string text, string title, MessageBoxButton button, MessageBoxImage icon); } } /// <summary> /// MVVM的メッセージボックスを表示するためのイベントトリガー。 /// /// MessageBox メッセンジャーの発行するイベントで起動される。 /// </summary> public class MessageBoxTrigger : System.Windows.Interactivity.EventTrigger { public MessageBoxTrigger() : base(MessageBox.EventName) { SourceObject = MessageBox.Instance; } } }
2.トリガーアクションの実装例
MesssageBoxのトリガーから実行されるトリガーアクションクラスの実装例です。
MessageBox.Actionから派生した、MessageBoxActionクラスを実装しています。 メッセージボックスを表示して、その結果を返すクラスです。
このクラスから使っている MessageBox クラスは、System.Windows のものということに注意してください。
MessageBoxAction.cs
using System.Windows; namespace StudyDotNet.Triggers { /// <summary> /// メッセージボックスを表示するトリガーアクション /// </summary> public class MessageBoxAction : MessageBox.Action { protected override MessageBoxResult ShowMessage( string text, string title, MessageBoxButton button, MessageBoxImage icon) { var owner = Application.Current.Windows .OfType<Window>().SingleOrDefault( x => x.IsActive); if(owner == null) { owner = Window.GetWindow(AssociatedObject); } return System.Windows.MessageBox.Show( owner, text, (title != null ? title : Application.Current.MainWindow.Title), button, icon); } } }
追記(2017-03-29): メッセージボックスのオーナーウィンドウに、アクティブウィンドウを指定するようにしました。メッセージボックスが出ている場合はnullになりうるのでその場合は従来通りのウィンドウとしています。(c# - Refer to active Window in WPF? - Stack Overflow)
3.メインウィンドウ(MainWindow.xaml)の記述例
上のメッセージトリガーとトリガーアクションクラスは以下のように、Xamlに Interaction.Trigger 要素を追加します。
XMLの名前空間、xmlns:i
と xmlns:tr
の宣言にも注意。i
は、System.Windows.Interactibityを使用するためで、
tr
は、上記のトリガー/アクションを使用するためのものです。
<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" xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity" xmlns:tr="clr-namespace:StudyDotNet.Triggers" mc:Ignorable="d" Title="MainWindow" Height="350" Width="525"> <Window.DataContext> <vm:MainWindowViewModel/> </Window.DataContext> <!-- ここから --> <i:Interaction.Triggers> <tr:MessageBoxTrigger> <tr:MessageBoxAction /> </tr:MessageBoxTrigger> </i:Interaction.Triggers> <!-- ここまで --> <Grid> <Button x:Name="button" Content="Button" Command="{Binding SampleCommand}" HorizontalAlignment="Left" Margin="50,50,0,0" VerticalAlignment="Top" Width="75"/> </Grid> </Window>
4.メッセージボックスを表示する
使う側からは単純に、MessageBox.Showを呼び出すだけです。 System.Windows.MessageBoxとゴッチャにならないように注意は必要。
using System; using System.Windows.Input; using StudyDotNet.Triggers; namespace StudyDotNet.Commands { public class SampleCommand : ICommand { public event EventHandler CanExecuteChanged; public bool CanExecute(object parameter) { return true; } public void Execute(object parameter) { MessageBox.Show("MVVMバンザイ!"); } } }
いくつになってもお勉強
これによって、より少ない変更で、従来のメッセージボックス使用部分をメッセンジャーパターンに移行できます。
ユニットテストは、固定の応答を返すスタブで対応。
また、別の表示方法に切り替えるのも容易です。
例えば独自のウィンドウで表示したり、 ポップアップせずメインウィンドウ内にメッセージを配置したり、 履歴を参照する機能を追加したりと、広がりがあります。
ということで、やはりビュー以外からは、表示内容やUIに直接の関わりを持たないほうが良いのでしょう。
いくつになってもお勉強です。
WPFのMVVMでコマンドをバインディングする利点
photo credit: Storm Trooper at Oxford via photopin (license)
MVVMパターンでは、ボタンを押した時の処理などは、コマンドにバインディングしましょうということらしく、 従来の「Clickイベントをコードビハインドで受けて、、、」というのは嫌われるらしい。
しかし理由なく「MVVMでなきゃダメ!」と言われても納得しがたい。 「なぜ?」にはちゃんと答えて欲しいですよね。
ということで、この際きちんと理解しようと頑張りました。
いくつになってもお勉強です。
コマンドの実装例
具体的に、コマンドを利用するには
- 実行したい処理を、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での「メッセンジャーパターン」という機構で回避できます。 ユニットテストでは簡単に応答を返すスタブに差し替えられます。 この「メッセンジャーパターン」については、以下のページに詳しく書いていますので是非。
いくつになってもお勉強
設計思想的には古くからあるDocument-ViewやMVCなどを最新技術で発展させたもののようですね。
古くはVC++のMFCアプリケーションでメニュー項目などを更新するUpdateUIなどと同じ便利さ加減と思います。便利なんだけどひと手間必要というのも同じですね。当時、あの機構をまともに理解している人が少なくて、往生した覚えがありますわって話が古くて伝わってない?
なにより、「どんな利点があるのか」という観点から、腰を据えて理解できて非常によかった。
フタを開ければかつて知ったる設計思想的な気分でもありました。
やっぱり、いくつになってもお勉強ですねー。
関連記事:
C#のラムダ式はAction・Funcと一緒に理解する
photo credit: Imperial Shuttle via photopin (license)
何事も表面的な丸暗記でなく、基礎からキッチリ理解するほうが結果的には早道ですね。
C#のラムダ式に関しては、ActionクラスととFuncクラスをしっかり理解しておけば、それほど難しくはないはずです。
C#のActionクラスは、戻り値のないメソッドを表すクラスで、Funcは戻り値のあるメソッドです。
どちらもジェネリッククラスで、Actionは引数リスト、Funcは戻り値の型と引数リストをジェネリックパラメータで指定します。
Actionはメソッドの動作内容に注目した名前であり、Funcは数学的な関数として評価値を持つ(=戻り値がある)ということですね。
この2つのクラスについては以下のページで詳しく書いていますので参照してください。
C#のラムダ式
ラムダ式の記法的には、以下のような感じ。引数がひとつなら丸かっこは不要とか、波かっこの中身が単一の文なら(複文でないなら)波かっこは要らないとか、いろいろあるんだけど、基本はこちらで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のラムダ式は無名クラスのインスタンスなんですね。 言語によって扱いが異なるのは興味深いがヤヤコシイ。