Delphiでユーザーインターフェイスを開発するためのMVCアプローチ。 パート1.チェックマーク

この記事は面白いものではなく、むしろ技術的なものなので、美しい紹介文は書きません。 その中で、私はMVCスタイルの古典的なDelphiデスクトップアプリケーション用のユーザーインターフェイスプログラミング手法に注目したい。 これは、後続のシリーズの入門記事です。

まだ猫の下でこの開発環境を使用している少数の人々に尋ねます。





クラシックアプリケーションとは、VCLに基づいたWindows用のデスクトップGUIアプリケーションを意味します。 Delphiの新しいバージョンに登場したFireMonkeyフレームワークについて、他の誰かに記事を書かせてください。

ユーザーインターフェイスは非常に多様です。 そして、ウェブ上でそれらが一般に完全な動物園である場合、デスクトップアプリケーションではすべてがより保守的に行われます。 もちろん、一部のアプリケーション（Skype、Mikogo、Office 2010を参照）の開発者は、使いやすさをさらに向上させるように設計されたあらゆる種類の視覚的なトリックを考え出し続けていますが、私たち（古い学校の人々）のほとんどは、標準のWindowsおよびVCLコントロールを発明しましたおそらくWindows 3.1の時代に遡ります。

-ボタン（TButton）

-チェックマーク（TCheckBox）

-スイッチ（ラジオボタン、TRadioButton）

-単一行入力フィールド（TEdit）

-複数行の入力フィールド（TMemoまたはTRichEdit）

-あらゆる種類の複合コントロール（TSpinEdit、TDateTimeEdit）

-マルチページコントロール（TPageControl、TTabControl）

-グリッド

-パネル、グループボックス、ベベル、シェイプ、ImageBoxなど



ユーザーインターフェースを作成する際の主なタスクは、上記の要素を使用してプログラムの内部データをこのように表現することです。これにより、ユーザーがこのデータを操作しやすくなります。 さて、あるいはその一方で、ユーザーがプログラムに彼から何を聞くべきかをプログラムに伝えることができるような要素のセットを考え出します。

要素のレイアウトの観点からインターフェースを設計することは、それ自体かなり複雑で重要なタスクです。 インターフェースは、ユーザーがプログラムと対話するための主要な手段です（Ctrl + Alt + Delによる削除はカウントされません）。 だからこそ、ユーザーからフィードバックを受け取るたびにインターフェイスを反復的に設計する必要があるのは、ユーザーがプログラムを操作するのに便利なのか、マウスを200回クリックする必要があるのか​​、サブウィンドウ（最後にはモーダルでもある）に移動するのか、10同じデータを一度入力すると、ウィンドウに再入力したときに保存されないためです。 など （私は、洗練された読者が、ユーザーインターフェースがすべきでないもののより多くの例を与えることができると確信しています:)）。



インターフェース設計を真剣かつ徹底的にとる海洋の賢い人は、プログラムで作業するときにマウスの動きを追跡する（無駄に戻さないようにする）、クリックをカウントする、ユーザーの視線の方向を追跡するなどの技術も使用すると言われています目がランダムな方向に走り始めます。これは驚くべきことです）。

しかし、この記事はこれらの奇跡についてではありません。 このウィンドウまたはそのウィンドウがどのように表示されるかを既に理解していることを前提としています。 どういうわけか、このビューをプログラムの内部データに接続する必要があります。 そして、この接続の方法について具体的にお話したいと思います。

プリミティブから始めましょう。 チェックマーク

あるウィンドウ（TCheckBox）にチェックマークがあり、2つのオプションのいずれかの選択を反映しているとします。 真空中の球形の馬について話さないために、何らかの意味を与えます。 特定のディレクトリのファイルからデータベースにデータをインポートするためのウィンドウとします。 チェックマークは、操作の完了後にインポートされたファイルを削除するかどうかを反映します。 次に、チェックマークを呼び出しましょう

cbNeedDeleteFiles: TCheckBox;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、コントロールの種類に基づいてコントロール名にプレフィックスを付けることは非常に便利です。 たとえば、TCheckBoxの場合はcb、TRadioButtonの場合はrb、TButtonの場合はbtです。 DelphiにcnPack拡張パッケージをインストールした場合、フォームに次のコントロールを配置すると、規則に従ってこのコントロールの名前をすぐに変更する提案がウィンドウにポップアップ表示されます。 これにより、フォーム上にあるButton87、CheckBox32などの優位性が回避されます。



原則として、フォーム上の適切な場所にコントロールを配置した後、プログラマは安心してため息をつき、落ち着きます。 これで、プログラム内のどこからでもcbNeedDeleteFiles.Checkedにアクセスして、チェックマークが付いているかどうかを確認できます。 おそらく、プログラマーは単一の場所でCheckedプロパティにアクセスしません。ウィンドウを作成するときに、このプロパティまたはその保存値のデフォルト状態を設定したい場合があります。その後、メインの場所（インポートが実行される場所）で、この属性を再度確認する必要があります。ウィンドウを閉じるときにこの属性の値を保存し、次にウィンドウを開いたときにチェックマークの状態を復元します。 他の条件に基づいて、この属性の値をプログラムで変更する必要がある場合もあります。 たとえば、ユーザーが入力ファイルのあるディレクトリが選択された場合、このディレクトリに厳密に定義されたタイプのファイルのみが含まれている場合、またはすべてのディレクトリファイルの名前が特定のマスクを満たす場合、このチェックボックスが常に自動的に表示されるように求めることができます。 したがって、プログラムの場所の山には、次のようなものが表示されます。

 if cbNeedDeleteFiles.Checked then ... if Something then cbNeedDeleteFiles.Checked := True; if SomethingElse then cbNeedDeleteFiles.Checked := False;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一見、それは何も悪いことではありません。 しかし、長期的な実践が示すように、それは素晴らしいです。 これは、ユーザーインターフェイスへのタイトリンクと呼ばれます。 後でTCheckBoxを「インポートしたファイルを削除する」と「インポートしたファイルを削除しないでください」の2つのラジオボタンに置​​き換える必要があるとします。 これはあまり意味がありませんが、視覚化を改善するため、または「インポートエラーがない場合のみファイルを削除する」など、この設定の3番目の状態を追加する前にリファクタリングの一部として行うことができます。 その瞬間、RadioButtonで作業するためのコードを、cbNeedDeleteFiles.Checkedへの連絡に使用していた場所のヒープに配置する必要があります。

これを避ける方法は？

ネットワーク上で長い間、 MVC 、 MVP 、 MVVMについて多くのトランペットをしていました。 これらはこのような奇跡的な手法であるかのように、ユーザーインターフェイスを「正しく」プログラムでき、上記のがらくたはありません。 実際、これらは本当に役立つアプローチにすぎませんが、異なるプログラミング言語、さらには1つの言語でもまったく異なる方法で実装できます。 つまり これらはどちらの側がユーザーインターフェイスプログラミングに最適であるかというかなりのヒントです。

略語をもう一度見ると、3つすべてに文字M（モデル、モデル）とV（ビュー、ビュー）があることがわかります。 非常に単純な言語で言えば、モデルはプログラムの内部データであり、プレゼンテーションは外部（ユーザーインターフェイス）です。 チェックマークに戻ると、ブール値がこのチェックマークの内部表現であることは明らかです。 どのクラス属性をこの値に格納するかの決定は、それぞれの場合に個別に行われます。 たとえば、プログラム設定へのアクセスを提供するTConfigクラスにすることができます。 ただし、単純な場合、フォームクラスだけに対応する属性を作成するだけで十分です。

 TfmImport = class(TForm) ... private ... FNeedDeleteFiles: Boolean; public ... property NeedDeleteFiles: Boolean read FNeedDeleteFiles write SetNeedDeleteFiles; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、NeedDeleteFilesプロパティの状態をビジュアルコンポーネント（TCheckBox）cbNeedDeleteFilesの状態に関連付ける必要があります。 これは、プロパティ設定メソッドを使用して簡単に実行できます。

 procedure TfmImport.SetNeedDeleteFiles(const Value: Boolean); begin if FNeedDeleteFiles <> Value then begin FNeedDeleteFiles := Value; cbNeedDeleteFiles.Checked := FNeedDeleteFiles; end; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FNeedDeleteFiles <> Value条件が必要な理由少し後で説明します。 主なことは、NeedDeleteFilesプロパティに値を割り当てると、自動的にチェックされることです（これはほとんどMVCモデルです-モデル要素の値を変更すると、ビューが自動的に変更されます）。 ただし、この接続は、内部データからインターフェイスへの1つの方法にすぎません。 ビュー（つまり、チェックマーク）からモデルへのフィードバックを達成する必要があります。 これを行うには、チェックボックスのOnClickハンドラーに次のコードを記述します。

 procedure TfmImport.cbNeedDeleteFilesClick(Sender: TObject); begin NeedDeleteFiles := cbNeedDeleteFiles.Checked; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり ビューに対するアクション（この場合、チェックマークをクリックする）は、モデルをビューの現在の状態に合わせます。 ただし、モデルはビューを決して信頼しないため、ビューの状態がモデルの状態に戻ります（force cbNeedDeleteFiles.Checked：= FNeedDeleteFiles。これに問題はありません。FNeedDeleteFiles<> OnClickハンドラーは再度呼び出しますが、実際には同様のチェックがあるため、呼び出しません。

 procedure TCustomCheckBox.SetChecked(Value: Boolean); begin if Value then State := cbChecked else State := cbUnchecked; end; procedure TCustomCheckBox.SetState(Value: TCheckBoxState); begin if FState <> Value then begin FState := Value; ... end; end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、TfmImport.NeedDeleteFilesプロパティの状態が、両方向のdaw状態cbNeedDeleteFiles.Checkedと同期しました。 cbNeedDeleteFiles.Checkedへのアクセスに使用したプログラムのすべての場所で、NeedDeleteFilesプロパティにアクセスする必要があります。 これにより、NeedDeleteFiles要素の表現がCheckBoxであることを完全に忘れることができます。 これがどれほど素晴らしいか想像することさえできません。 その後、CheckBoxを2つのラジオボタンなどに置き換えることができます。SetNeedDeleteFilessetメソッド（Model-> View direction）と、ビューステートが変更されたときに起動するハンドラーのみで書き換える必要があります。 視覚コンポーネント（表示->モデルの方向）。



NeedDeleteFilesプロパティの値とビジュアルコンポーネントの状態の初期同期などの重要なポイントを見逃しました。 もちろん、ウィンドウを開いたときに、dawが常に設定または常にオフになっている場合、DesignTimeで正しい状態を設定し、フォームクラスのOnCreateでFNeedDeleteFilesフィールドに対応する値を割り当てることができます。 ただし、これはあまり信頼性が高くないため（これに従う必要があり、矛盾を避けるのは簡単です）、したがって、OnCreateでは、フォームクラスが次のコードを配置する方が適切です。

 procedure TfmImport.FormCreate(Sender: TObject); begin FNeedDeleteFiles := False; //   ,   ,   ,   set- NeedDeleteFiles := True; //   set-   GUI    ( ) end;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

記事の次の部分では、より複雑なケースについて説明します：要素のリスト（TListBox、TCheckListBox、TComboBox）を使用したMVCスタイルでの作業と、ウィンドウが閉じられたときの視覚要素の状態を記憶する際の落とし穴について。



UPD。 記事の2番目の部分が追加されます。

UPD。 記事の3番目の部分が追加されます。