前回まで 6 回にわたり、Google マップ の Place API の検索機能を題材にクラス化する作業を体験しました。結果を振り返りながら、クラス化の作業について整理しましょう。
改めて、今回作成したライブラリをデザイナーで確認してみます。全体を眺めると見えてくることがあります。
カプセル化
まず、最初に感じるのはスッキリ感ですね。
クラスを使用しない開発の場合、ライブラリに関数が増えてくると、煩雑になり、必要なものを探すのに苦労するようになります。名称順に並んではくれますが、機能的関連性はわかりません。名称を工夫する必要が出てきますが、数が多くなると悩ましくなってきます。
クラスは階層化して表示されます。そして、その階層の中にはクラスに関係があるものが集約されています。整理された状態になっており、気持ちがいいですね。
このように集約してまとめることをオブジェクト指向の世界では『カプセル化』というようです。
インターフェースの明確化と隠蔽
デザイナーでは Private な関数や変数には黄色の■がアイコン表示されています。これが付いていないものが Public となります。このマークを見れば、インターフェースとなるプロパティやメソッドがわかるということですね。
インターフェースを明確にするのは、不用意にデータにアクセスさせないなど、クラスが持つ機能やデータを安全に利用することが目的です。
プロパティで入力チェックを行い合格したデータだけを採用（メンバ変数にセット）したり、内部で利用するだけの関数を Private 化するなど、クラスの利用者が想定外の操作をしないようにして、安全性を高めます。このような考え方を『隠蔽』といいます。
命名規則
インターフェースとなるプロパティやメソッドは Count や Search など簡潔で端的な名称としています。クラス内に作成するメンバ変数や Private な関数には接頭文字として z をつけており、一覧で下の方に集まるようにしています。
結果的に、インターフェースが上に集まり目立つということですね。
複数のクラスで使用しそうな汎用的な関数（xGetElementByName_Obj や xGetLocation）はクラス外で定義されています。クラス外であることがわかるよう接頭文字は x としています。
関数の命名を少し工夫するだけで、さらにわかりやすいプログラムになりますね。
デバッガとクラス
クラスを利用した開発でデバッガを利用するには注意が必要です。
まずは不便な点、下図のイベント欄です。
クラスの名称や実行中の関数などが表示されず Declarations と表示されています。実際には NearBySearch クラスの Search メソッドを実行中なのですが表示されていません。
ステップ実行して確認するだけであれば、あまり気になりませんが、クラス内の Private 関数にブレークポイントをセットする場合など、クラス内を横断的に見たいときには、その場所を探すが大変です。
イベント欄にクラスを表示して、クラスを選択したら右にクラス内の関数を表示するなど、改善してほしいですね。
Notes 8 以降、スタンダード版のデザイナーが提供されるようになって、クラスが階層化して表示されるなど、クラス開発の効率がずいぶん上がりました。ただ、デバッガの機能は進化がなく旧来のままとなっています。機能強化が待たれますね。
デバッガの変数のタブは見方に少し注意がが必要です。下図は NearBySearch クラスの Search メソッドを実行中の、変数タブの状態です。
関数内の変数に混ざって、ME という変数があります。これが、Search メソッドを実行してるクラスのインスタンス（自分自身）を表します。中を確認すると、クラスのメンバ変数とその値が確認できます。NotesDocument などノーツオブジェクトクラスの場合はプロパティの値が見えますが、ユーザ定義クラスではプロパティとしては確認できません。
なお、3 列目の型には NEARBYSEARCH とクラス名が表示されています。また、zoLocation のようにメンバ変数内にユーザ定義クラスのインスタンスがある場合、そのメンバ変数がさらに階層化されて表示されます。
