初めに

内容は連載予定です。

• 設計とビュー以外実装編(本記事)
• ビュー実装編(執筆予定)

教材を元に振り返り解説していきます。

誰向けの記事か？

• 気軽にWPFアプリを作れるようになりたい方
• 程よい規模のWPFアプリのソースコードを参考にしたい方
• MVVM入門してみたが身につかなかった方

教材

JitPad

解説用に用意したアプリではなく実用しているアプリを元に解説します。
C#コードを逐次逆アセンブルしx64コードを表示するアプリです。使うだけなら本記事の内容の理解は必要ありません。こちらからダウンロードしてご利用ください。

このコミットを元に解説していきます。
https://github.com/YoshihiroIto/JitPad/tree/8315f7fda1857e0403f13e863e83f2a321c3f062

アプリ動作イメージ

設計

問題領域の整理把握と問題領域内オブジェクトの洗い出しを行いました。
初期段階で完璧なものを用意するのは現実的ではなく、ある程度のものができれば一歩前進です。

問題領域

「C#コード」を受け取り「結果（x64コード）」を出力

問題領域はこれだけです。そしてこれがユーザー観点の目的です。

他は外野。例えばGUI実装が代表的な外野領域です。GUIアプリだといっても問題領域にGUIは含まれない。

大事なことは問題解決そのものに最大限の価値を置くこと。ユーザー観点目的を最大限の価値に置くと最終的なアプリの仕上がりに差がでます。

一方通行関係

外野は問題領域に依存しているけど問題領域は外野に依存しない、一歩通行関係。

問題領域内のオブジェクトは問題解決のために尽力できなければいけない。
問題領域解決するのが目的、だから問題解決に全力を務める。外野は邪魔しない、文句言わない！

一歩通行ではなくお互いに関係を持つとどうなるでしょう。
自身変更時に依存先を考慮、依存先は自身に依存している、で自身を再調整して・・・。収拾つかない、巨大な泥団子の出来上がりです。

問題領域内のオブジェクトたち

問題領域を解決するにあたり、複数オブジェクトの連携が必要です。
オブジェクト間も闇雲に依存するのではなく一方通行関係を作ります。理由は同じくです。

実装

名前空間 JitPad.Core 内のクラスが問題領域を扱います。
問題領域の解決には複数オブジェクトが連携して行われます。

主要クラスと役割

• AppCore アプリ実態
• Config アプリ設定
• BuildingUnit
  • ビルド単位
  • 指定のコンフィグで、コンパイルして逆アセンブルし結果を出力
  • 実行時には指定のコンパイラ、JIT逆コンパイラを使う。

ビルド単位

BuildingUnit はソースコードが入力されると指定コンフィグでビルド処理を行います。
依存するオブジェクト (コンパイラ、逆アセンブラ、コンフィグ)の詳細は関心外なので、構築時にを要求しこれらを組み合わせて処理します。

まとめ

いざWPFアプリ開発となると、いきなり見てくれから作り始めてしまうこと必至ですが、ちょっと待って。
まずは問題領域を整理把握しましょうという話でした。

問題領域が整理把握実装できていれば、それに合わせてGUIが作れるというものです。

実装者のWPF習熟度にもよりますがGUIから作り始めたところ限界がきて、
「WPFの都合でーー」
とか言われて(ホント？)、低品質アプリが出来上がってしまういくつかの現場を見てきました。

アプリを使うユーザーはただ目的が達したいだけ、GUIを触ることは目的外。
目的が果たせれば GUI なんていらないです。
GUIを用意するのであれば、目的を心地よく果たせるものを用意したいものです。

ということで、次回はビュー実装編、乞うご期待。