ひがやすを技術ブログ

電通国際情報サービスのプログラマ

単方向バインディングと双方向バインディング

Flex

Flex2では、モデルとUIコンポーネントと間の自動バインディングがサポートされています。自動バインディングとは､モデルの値が更新されたら自動的にUIコンポーネントの表示が更新されたり､UIコンポーネントに入力している値が変わったら､自動的にモデルの値を更新する機能です。
デフォルトではバインディングは単方向です。基本的には､モデルの変更をUIコンポーネントが検知するだけ。例えば､次のようなMXMLがあったとします。

<?xml version="1.0" encoding="utf-8"?>

    
        <![CDATA[
           [Bindable]
           private var hoge:String;
        ]]>

これは、単方向バインディングなので、TextInputに入力した内容は、hoge変数には反映されません。したがって、TextInputに何か入力してもLabelには反映されません。ここで、次のようにBindingタグを使うと双方向バインディングにできます。

<?xml version="1.0" encoding="utf-8"?>

    
        <![CDATA[
           [Bindable]
           private var hoge:String;
        ]]>

これは、双方向バインディングなので、TextInputに入力した内容は、hoge変数に反映され、さらにhoge変数の変更がLabelに反映されるため、TextInputに入力した内容がLabelに反映されます。

業務アプリケーションは結局関数と構造体だけあれば充分?

etc

2〜3年ほど前から感じていることですが、結局関数と構造体だけあれば充分なのではないかと。

ユーザの要件を実現する業務ロジックだけに限っていえば､関数と構造体だけでうまくいくケースもあるでしょうね。Cの時代はそうしていたわけだし。ただ、ここで重要なのは､これは極論ジャンと流したり､単純に反論するだけでなく､なぜそう思えるのかを考えてみることです。
私たちが会社でこなしているような業務というのは､伝票と呼ばれるデータとそれに対する回覧・承認・変更といったアクティビティで成り立っています。これを素直にモデル化すると、伝票は構造体になり､アクティビティは関数になるでしょう。だから、そんなに変なことではないと思います。業務を関数と構造体で表すのは。
ただ、Cの時代とは違って今のJavaは進んでいます。構造体は､正規化されてエンティティ(テーブルに近い構造)の組み合わせになり､関数は共通的なかたまりごとにインターフェースに切り出され､実際に使われるときは､DIされて業務ロジック用のコンポーネントになるのです。
まぁ、このあたりは昔から何度も言っているんですが､よくナイーブ(稚拙)なオブジェクト指向信者が必ず反論してきます。エンティティに振る舞いがないなんて「ドメインモデル貧血症」だと。
私は､エンティティに振る舞いが割り振られているのが良いオブジェクト指向ではなく､より現実のモデルをうまく写像しているのが良いモデルだと思っています。常に現実の変更にうまく対応していけるからです。現実のモデルとJavaのモデルが大きく異なるとしたら現実の変更に対応するコストが大きくなってしまうでしょう。
私たちが業務で行っているようなことは､伝票とアクティビティを素直にエンティティとアクティビティ用のインターフェースにマッピングするのがいちばん簡単で変更にも強くなると思います。また本質的なことではありませんがDIと非常に相性が良い。
エンティティに振る舞いを与えようとするドメインモデルは、現実との乖離があるだけでなく､結構DIと相性が悪いと思います。