標準モジュールとクラスについて (ID:147003)

名前

ホームページ(ブログ、Twitterなど)のURL (省略可)

本文 > 標準モジュールを「既存の項目の追加→リンクとして追加」 > にするかクラス化するか迷っています。 管理方法に対する相談なのか、Class と Module の使い分けなのか 質問内容がはっきりしていないように感じますが、とりあえず クラスであっても、リンクとして追加する事はできますし、 標準モジュールであっても DLL 等にすることはできるでしょう。 このあたりは、VB6 とは事情が異なるところですね。 > そして、vb2005に変えるにあたり 2010 では無く? VB/VS 2005 の標準サポートは今年度までとなっています。ご注意あれ。 正確にいえば、2011/04/12 に VB2005 のメインストリーム サポートが 終了するという事です。延長サポートはまだ続きますけれどね。 > クラス化が良いみたいなのですが 何が良いのか、その具体的な理由を調査・検証された上での悩みでしょうか? VB6 時代にクラスを使わず、標準モジュールを使っていた理由は何でしょうか。 モジュールの方にメリットを感じていた(またはクラスでは都合が悪かった)なら、 それを今回、改善できるかどうかを調べておく必要があるかと思います。 たとえば、開発メンバーの知識やスキル等が不足していたからというのが クラスを採用していなかった理由なのであれば、上司に説明する際には、 その対応策を考えておかなければなりませんよね。 > メリット、デメリット等ご教授お願いします。 教授→教示のツッコミはさておき、今回の質問というのは、 ソースをリンクするべきか、ソースをコピー利用するべきか、 DLL にしてプロジェクトに含めるべきか、GAC 登録すべきかという 視点ではなく、標準モジュールの是非に関してでしょうか。 言語的な機能だけで見るならば、2008 未満のバージョンでは、 「標準モジュールが無いと困る」というケースは無いはずです。 極端な話、シングルトンにしたり、Shared メンバーを使ったりすれば、 標準モジュールの機能をそのまま踏襲させることはできるわけですから、 その意味においては、クラスを使えば事足りると言う事ができるでしょう。 もっとも、そのような実装方法が良いことかどうかは別の話ですが。 > 管理方法を変更してまでクラス化するメリットを たとえば「インスタンス」「インターフェイスの実装」などは、 標準モジュールでは表現できません。デザインパターンを意識した開発が 出来る場合には、クラスの方が便利な事が多いと思います。 しかし、正しいクラス設計をするには、ある程度の力量が必要になってきます。 (もっとも、それは Form 等に対しても言える事なのですが) 元の *.bas が、カプセル化を意識して作成されたコードであるならば さほど問題ありませんが、単に Public/Global なメンバーを並べただけの 物であるならば、それをただ Class に置き換えただけでは、むしろ 手順が煩雑化する分、デメリットの方が増大する可能性もありえます。 # 移植元の標準モジュールの内容を知らないので、この場では判断できませんが。