ぜーたのブログ一覧

CollectionとDictionary辺りの所謂連想配列と言われるものを勉強し始めると、セットでクラスモジュールを勉強する必要を迫られます。

多分、この次に出てくるのが、ユーザーフォームと自作イベントだと思います。

どちらもクラスで操作しないと、扱うのが難しいと思います。

流石にVBA初心者は脱却したと思っていますが、現状オブジェクト指向的な考え方で構造的に設計を行う事が出来ていません。

一つのプロシージャーには一つの役割を持たせる、それを組み合わせる事で、クラス自体にもある決まった役割を持たせる、また役割を線引して互いに干渉、依存しないようにしないといけない。

何となく意味はわかるのですが、それを実際のコードに落とし込むのが難しい訳です。

こういう時にやはりAIは必要になってきます。

人間より遥かに論理的にまとめて、いかにも人間らしい言い回しで答えてくれるので、プログラミングとAIはめちゃくちゃ相性が良いですよね。

時間は有限なので、利用出来るものは利用して、無駄な時間を減らしたいものです。

凡人は天才にはなれません。

努力すれば結果が出る時代は終わりました。

余計な拘りや信念は捨てて良いです。

出来てしまえば、それで良いと思わねばなりません。

VBAで代入する変数を動的に変更したい時にCallByName関数が便利みたいです。

クラスのメンバ変数に、処理した結果を順番に代入したいとなると、変数の数だけコードが必要になってくる訳です。

もしそれが同じ処理なのであれば、変数名をCollectionかDictionary、もしくは配列でも良いですが、変数名を予め代入しておきFor文でCallByName関数を介して回してやれば、それ一発で済みます。

予め変数名を代入して用意しておく手間は必要ですが、圧倒的にコード量が減るし、こちらの方が可読性も高いと思います。

ちなみにこのCallByName関数で気付いたのが、クラス内からMeキーワードを利用してメンバ変数を代入(VbLet)する際に、変数のスコープがPrivateだとコンパイルを通りません。

変数のスコープをPublicかFriendにするか、Propertyを設定してやる必要があります。

クラス内部に記載しても、外部からのアクセスと同じ扱いになるようです。

CallByName関数は同じメソッドで別々の処理をさせるポリモーフィズムにも使えますが、逆に別々の変数に同じ処理を適応したい時にも使えますね。

VBAでポリモーフィズムを行うには、Object型の変数を利用する、CallByName関数を利用する、Imprementsキーワードを利用する、の3つがあるかと思います。

どちらにしてもクラスモジュールが必要になってきますが、身の回りのマクロにクラスモジュールが使われているのを見た事がありません。

個人用にはクラスモジュールを積極的に利用している、と言うかクラスモジュールを使わないと標準モジュールにめちゃくちゃ複雑なコードを書かないといけなくなるケースが多いです。

オブジェクト指向を理解する上でもクラスの考え方は重要だと思うし、あるのに使わないのは勿体ないですね。

VBAあるあるの代表格として、変数にオブジェクト代入時の「Setの付け忘れ」があると思います。

FunctionのReturnの時とか、引数でCollectionを受け渡す時とか、慣れた人でもウッカリやってしまうアレです。

ところが、オブジェクトでもPropertyから代入する時はLetでもイケてしまう謎現象が起こります。

Property内での代入はSetが必要になってきますが、それを受け取るのはLetでも問題ないのです。

Property LetにオブジェクトをSet無しで渡しても、コンパイルが通ってしまうし、実行エラーにもなりません。

ただし、PropertyがSetになっていたら、オブジェクトを渡す時もSetが必要になりますし、逆にプリミティブ型をSetで渡すなんて事は出来ません。

まぁ、これを何かの役に立てようなんて思うと混乱の元ですので、素直にオブジェクト型はSet、プリミティブ型はLetで統一した方が良さそうです。

.NETからはオブジェクトもSetが要らないみたいなので楽ちんで良いですが、VBA人はSetを付け忘れないように気を抜いてはいけないのです。

インターフェースを利用すれば、引数やメソッドの実装が保証されるので、コレクションに必要なクラスを全て代入してしまえば、For eachで回せる訳ですね。

考え方としては、インターフェースは予め設定しておくもので、後から追加するものではないという事ですね。

ある程度の規模のマクロになると、確かにインターフェースを利用した方が「簡単になる」と思います。

サブルーチンを作れば共通の処理はまとめられますが、インターフェースを実装すれば共通ではない処理をまとめられますね。

使い道は沢山あるはずなんです。

エクセルブックも、ワークシートも、セルも、クラスですが、本当にエクセルを使いこなせる人はなかなかいないので、大半のメソッドやプロパティは使われないまま存在していると思います。

それと同じように、時々しか使わないメンバを沢山持っているけど、いざ必要という時にすぐ使えるような汎用性の高いクラスを作りたいのです。

出来る限り決め打ちせずに、引数を与える事で上手くコントロールして柔軟に対応出来るようにしたいのです。

動けば良いマクロは組もうと思えばいくらでも組めるので、保守性が高く、そして属人化しないように設計する事からやってみたいと思うのです。

勉強し始めた当初は「どうやったら良い」のかを考えてしました。

今思うのは「どうやっても良い」という事です。

本人の意思によって作り始めるものなら、何の制限もありません。

方法は自由です。

VBAは完璧なオブジェクト指向言語ではありませんが、折角クラスモジュールがあるのですから、十分に活用していきたいものです。