[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re^4: フォームの重ね順番制御について？ 投稿日 ： 2016/10/26(Wed) 19:45 投稿者 ： 魔界の仮面弁士
| > 疑問だらけのコードで１行１行確認しています 数行だけのコードなので、コードそのものは難しくないと思いますが、 どうしてそれで回避できるのかは、ちょっとわかりにくいかも知れませんね。 > それは Friend Property Get IsDebug() As Boolean という箇所です えぇと、その部分は VB2005 向けのコードではなく、 VB6 用のものですが構いませんか? 今回作成した IsDebug プロパティというのは、 VB2005 でいうところの「Debugger.IsAttached」に相当するものです。 開発環境からのデバッグ実行時には True を返し、 コンパイルして EXE として実行すると False を返します。 この Boolean 値は、実行中に変化する事が無い値なので、 実際には毎回 OnDebug を呼び出すのではなく、一度調べた値を 使い回すようなプロパティ実装にした方が良かったかも知れません。 > 自分の今までの概念ではFunction です ザックリ言えば、メソッド(Sub/Function)は「操作」。 そのオブジェクトの振る舞いを表します。 一方、プロパティ(Property)は「データ」や「状態」を 表すものです。この観点で使い分けています。 https://msdn.microsoft.com/ja-jp/library/ms229054.aspx 今回は、「デバッグモードか否か」という状態を返す実装と 位置づけたため、IsDebug プロパティとして実装しました。 VB.NET なら先述した Debugger.IsAttached プロパティ。 VB6 なら、ADODB.Connection の State プロパティとか、 UserControl の Ambient.UserMode プロパティとか、 あるいは App.StartMode プロパティなどをイメージしています。 とはいえ、無理にプロパティに拘る必要もないかと思います。 これを「デバッグモードかどうかを調べる『動作』である」 と考える場合は、メソッドとして実装しても良いと思いますし。 > 使う場面がよくわかっていません 自分自身、感覚で使い分けている部分が大きく、 あらためて質問されると、その使い分け方を 明確に説明できそうにありません…。(^^; ちょいと脱線して、VB6の「CommonDialog」コントロールの実装。 VB2 の頃は、 CommonDialog1.Action = 1 CommonDialog1.Action = 3 CommonDialog1.Action = 4 のように、Action プロパティをセットすることでダイアログを 表示させていました（技術的な理由もあったようですが）。 それが VB4 段階の実装では、プロパティ呼び出しは非推奨とされ、 Call CommonDialog1.ShowOpen Call CommonDialog1.ShowColor Call CommonDialog1.ShowFont のように、メソッド呼び出しで表示させるように変わっています。 これは、「動作」を指示するものであるのなら、メソッドの方が 望ましいという判断によるものだと思います。 これが .NET だと、ダイアログの種類ごとに別のクラスに 分離されたわけですが……Microsoft でさえこうした揺らぎが あったわけですし、明確な使い分けルールの提示は難しそうです。 > なぜここで Friend Property を使うとよいのか スコープを Friend にした理由に付いては、そもそも Public にする必要が無いと考えてのことです。 何しろ、開発環境かどうかを「別のプロジェクト」から調べることは ありえませんから。(別プロジェクトから呼ぶには DLL 化する必要があり、 その場合、IsDebug は常に False を返すことになりますので) 「自プロジェクト」からしか呼ばれないわけですから、スコープとして 選択肢に挙がるのは、Private または Friend のいずれかです。 その上で、今回は自クラス以外からも再利用できるようにと考え、 Friend を選択した次第です。 ただ、今にして思えば、Private の方が適切だったかもしれません。 （この点は、メソッドかプロパティかという問題とは別の話です） そもそも「ThunderMain クラスがデバッグモードかどうか」を 調べている訳ではないので、ThunderMain の公開メンバーとして 実装されるのは不自然な気もしてきました。……非公開で十分だったかも。 でもって、なぜ Function ではなく Property Get にしたのかという点については、 先に述べた内容以上の理由は、特に持ち合わせていません。 メソッドとプロパティの使い分け方を、強いて例示するとすれば、 下記のようなイメージで考えています。 実装する段階で、プロパティにするかメソッドにするか悩む場合もありますが…。 ------------ (1) 値の取得処理が軽量なケース、特に、内部のモジュール変数を 単純にカプセル化したものはプロパティにしています。 いわゆる「バッキングフィールド」への間接的なアクセス手段を用意するケース。 一番多いのがこのパターンかも。 実際には「バッキングフィールドを公開するためにプロパティを作る」のではなく 「プロパティを実装する手段としてバッキングフィールドを用意する」ことが多いです。 ------------ (2) 値の取得が比較的低速な場合は、メソッドを選択します。 今回の IsDebug は、実行中に値が変化するようなものでも無いですし、 さほど複雑な処理でもなく、十分に高速であるということで、 プロパティとして実装させました。 何を持って「低速」「高速」とするか線引きを聞かれると困りますが、 先の(1)のように、自身の内部データを取り出すだけなら、 プロパティでも良いのかな、と。 ------------ (3) 引数を伴う処理はメソッドとして実装します。 プロパティに引数を付けるケースは非常に稀です。 たとえば ListBox.List のように、インデクサのような 振舞いにする場合はプロパティとして実装されますが、 それ以外のケースで引数を使う必要性は思い当たりません。 ADODB.Recordset の Collect プロパティもこの類ですね。 別パターンとしては、既存のプロパティを拡張するために、 省略可能な引数を付けるというケースがあります。 Excel はこれが意外と多くて困り者。(Range.Value プロパティなど) ------------ |
をクリックするとツリー全体を一括表示します） - フォームの重ね順番制御について - SUZUKI 16/10/11-16:53No.11743